feat(serve): surface a coarse startup phase while a service comes up

[michaelroy-amd]

Stacked on #106 (EAI-7350). Review/merge #106 first; this PR's base is fix/dash-instance-status, so its own diff is only the startup-phase work.

Summary

While a managed service is coming up, the dashboard showed only a generic STARTING label (or a spinner) with no indication of what it was doing — pulling weights, loading them onto the device, or warming up. A slow first launch was therefore indistinguishable from a hang. This PR surfaces a coarse startup phase (Downloading / Loading / Warmup) end to end.

Root Cause

The serve supervisor (apps/rocmd) already redirects the engine's stdout/stderr into the per-service log file, but wait_for_service_ready only polled a healthcheck RPC and never inspected that output. ManagedServiceRecord had no field to carry a startup stage, and the dashboard's InstanceStatus::Starting was a unit variant with nowhere to put one.

Changes

• rocm-core: add ManagedServiceRecord.startup_phase: Option<String> (#[serde(default)] so older on-disk records still deserialize), cleared back to None once the service reaches ready.
• rocmd: wait_for_service_ready now tails the service log while polling and reports each phase transition, which the caller persists to the record. Parsing is split into small pure, unit-tested helpers:
  • last_cr_segment collapses \r progress redraws (pip/tqdm/HF), the same rule the dashboard job console uses.
  • classify_startup_phase matches the common vLLM / llama.cpp / Hugging Face startup vocabulary into a downloading/loading/warmup token.
• rocm-dash-core: add a fieldless StartupPhase enum and change InstanceStatus::Starting to Starting { phase: Option<StartupPhase> }. StartupPhase is Copy, so InstanceStatus stays Copy — the only ripple is pattern shape (Starting { .. }), not a Copy-removal cascade. A new InstanceStatus::label() centralizes the status text (READY / DOWNLOADING / LOADING / WARMUP / …).
• rocm-dash-daemon (registry): map the record's startup_phase onto Starting { phase } for starting/recovering records; Docker discovery and the scrape-success promotion keep phase: None.
• rocm-dash-tui: status_meta/status_role and the services-manager list now render via label(), so the phase shows on instance cards, the detail pane, and the services list. Note: serving.rs is a static verb menu with no per-instance status rendering, so the live phase display lives in instances.rs + services_manager.rs (the actual instance-status surfaces).

Scope / Notes

• Phase detection is best-effort log scraping (no structured engine signal exists today); an unrecognized phase token degrades gracefully to a plain STARTING.
• The Starting serde wire shape changes from the bare string "starting" to an externally-tagged object; this only affects the in-version daemon socket/replay stream, and the round trip is covered by a new test.

Test Plan

• cargo build (workspace)
• cargo clippy --all-targets --all-features -- -D warnings (workspace, clean)
• cargo test -p rocm-core -p rocm-dash-core -p rocm-dash-collectors -p rocm-dash-daemon — green, incl. new tests: instance_status_label_surfaces_startup_phase, instance_status_starting_round_trips_through_serde, startup_phase_from_token_round_trips_labels, discovered_from_record_surfaces_startup_phase_while_starting
• cargo test -p rocmd --lib — 109 green, incl. last_cr_segment_keeps_final_progress_redraw, classify_startup_phase_maps_engine_vocabulary, classify_startup_phase_emits_only_dashboard_known_tokens, read_new_log_phase_advances_and_tracks_latest
• cargo test -p rocm-dash-tui -- --test-threads=1 — 543 + 16 + 5 green

Relates to EAI-7355