[volen-silo]

Implements ROCMAI-62.

Four gaps in dashboard telemetry, in four commits that each build on their own:

1. TTFT/TPOT expire. The windowed average fell back to the histogram's lifetime average whenever a scrape saw no new requests, so an idle server kept showing its all-time latency forever. Only windows with new requests now produce a value; it is held (marked *, with the existing legend) for the observation validity window and then cleared. Reuses GenerationObservationTracker::observe_direct. Instance gains ttft_observation/tpot_observation (serde-default, omitted when unknown, so old recordings load and are never labelled fresh).
2. Shared-GPU power attribution. Every instance was credited with the full board power of each GPU it touches, so two models on one GPU each claimed all of it. attribute_power_w splits a GPU's power among its occupants by per-container VRAM, falling back to an equal split when any occupant has no reading. Power on a GPU nobody occupies is attributed to no instance but still counts toward node power. Instance.power_w carries the share and feeds tok/W and the POWER column. Also fixes the registry view ignoring gpu_indices: instances from rocm serve always had empty gpu_ids, so they could never show power or tok/W.
3. Assistant tool output. list_instances now reports ttft_ms/tpot_ms with their freshness and the attributed power_w, so the assistant cannot present a held TTFT as live.
4. Power limit and thresholds. GpuMetrics.power_limit_w (serde-default; None = unknown, never 0) is read from amd-smi static on the existing 30 s system-info cadence. Warning colors are 70% / 93% of the device's own limit (where the old 525/700 W constants sat on a 750 W part). With no known limit the value is drawn uncolored instead of being judged against another part's TDP.

Not covered / caveats

• No Gherkin scenario. This changes what the dashboard shows, but the dash scenarios need the Linux PTY lane; I could not run one. Coverage is at the daemon level instead: ttft_is_held_then_cleared_when_requests_stop and shared_gpu_power_is_split_and_limit_is_reported in crates/rocm-dash-daemon/tests/telemetry_contract.rs drive the real runner loop against a fake Prometheus endpoint and a fake amd-smi. I confirmed the TTFT test fails with the old lifetime-average fallback restored.
• amd-smi static key unverified. The cap is read from limit.socket_power, then limit.max_power, per my understanding of the schema, and has not been checked against a real MI-series host. Parsing is defensive; an unrecognised shape yields no limit (uncolored), not a wrong color.
• Windows has no limit source. ADLX exposes none for the iGPU I tried (gpu_power_range is unsupported), so power is uncolored there. Windows also has no instance registry, so items 1-3 do not apply there yet.
• WSL. amd-smi cannot run on WSL (no amdgpu module), so there is no GPU power or limit there, and vLLM's platform detection fails on amdsmi. Not addressed here.
• Depends on nothing, but overlaps feat(dash-tui): collect GPU/memory metrics in-process on Windows #715. Its winperf.rs and a few tests build GpuMetrics with explicit fields; whichever PR merges second needs power_limit_w: None, added to those literals. Draft until feat(dash-tui): collect GPU/memory metrics in-process on Windows #715 lands.
• e2e-cucumber's two shared_runtime symlink tests fail on a Windows account without symlink privilege (os error 1314), independent of this change.

Verification

• cargo test --workspace --all-targets (Windows): all pass except the two symlink tests above. cargo clippy --workspace --all-targets -- -D warnings and python scripts/smoke_local.py clean.
• Dash crates, Linux (WSL, including the unix-only daemon tests): 301 passed.
• Ran feat(dash-tui): collect GPU/memory metrics in-process on Windows #715's WinPerfCollector on a Windows host with a Radeon 8060S to confirm the new field flows through (power reported, limit None).