fix(dash): rebuild live chat agent when a local endpoint is accepted

[michaelroy-amd]

Problem

In the dash TUI chat, accepting a detected local endpoint updated the config (chat_llm) but never rebuilt the live agent object that actually issues completions. The agent is built once at startup and only ever reassigned on a /provider switch. So after a user selected a local server (e.g. a Vulkan-backed lemonade running qwen3-0.6b), chat kept routing to the startup backend.

When that startup backend was a cloud gateway (an Azure API Management endpoint configured via chat_url + tui.chat_auth_header = "Ocp-Apim-Subscription-Key" + an env API key), every submit hit the gateway and returned:

chat request failed: ... 401 Unauthorized "Access denied due to invalid subscription key"

The UI showed the local endpoint as selected; the request physically went to Azure. chat_llm and the live agent had silently diverged.

Fix

Close the divergence with a one-shot chat_endpoint_rebuild edge (mirrors the existing chat_persist_dispatch / provider_switch edge-drain pattern):

• accept_detect_offer (and save_detect_offer via delegation) raises the edge and selects ChatProvider::Local.
• A new event_loop drain — placed after the /provider switch drain and before the chat_dispatch drain (ordering is load-bearing: otherwise the first post-accept submit would still use the stale agent) — rebuilds the live agent from the auth-free local chat_llm and refreshes the local_agent restore snapshot, so a later /provider local restores the accepted backend rather than the stale startup one. On build failure the agent is left unchanged and an error turn surfaces (mirrors /provider failure semantics).

Defense-in-depth

resolve_llm_config now strips api_key/auth_header when the resolved base_url host is loopback (127.0.0.0/8, localhost, ::1). This prevents a startup-configured local endpoint from leaking a cloud credential — a distinct code path the detect-accept fix does not cover.

Note: this is an intentional behavior change. A user pointing at a local authenticating proxy that genuinely requires an auth header (e.g. a corp gateway bound to 127.0.0.1) will have that header stripped. This matches detected_llm_config's existing no-auth-for-local stance and is documented in-code.

Tests

• Extended detect_offer_lifecycle_accept_switches_chat and save_detect_offer_accepts_and_raises_persist_edge to assert the rebuild edge is raised and the provider realigns to Local — starting from a non-Local provider so the realignment assertion is load-bearing rather than tautological.
• Added loopback_base_url_strips_cloud_auth and remote_base_url_keeps_cloud_auth unit tests for resolve_llm_config.

Verification

• cargo build -p rocm-dash-tui ✅
• cargo clippy -p rocm-dash-tui --all-targets -- -D warnings ✅ (clean)
• cargo test -p rocm-dash-tui -- --test-threads=1 ✅ — 533 lib + 16 + 5 tests pass, 0 failed

Notes for reviewers

The fix was developed with an adversarial multi-agent review pass. The rebuild-drain ordering (before chat_dispatch) and the local_agent snapshot refresh are the subtle, load-bearing pieces. The event-loop drain itself is covered indirectly (consistent with the pre-existing /provider drain, which is also not unit-tested beyond build_chat_agent invariants).

[juhovainio]

The auto-detect-and-switch flow is a nice UX addition. Several correctness issues in the new drain path and the loopback auth stripping below.

[juhovainio]

LGTM! Tested locally on WSL Ubuntu with Radeon 780M iGPU

Local model was detected:

And responses are received as expected:

[fredespi]

Cross-reference: #88 (EAI-7220) touches the same chat-endpoint flow but at a different layer, so the two are complementary rather than overlapping.

• This PR (fix(dash): rebuild live chat agent when a local endpoint is accepted #81) fixes the wiring: when a detected local endpoint is accepted, the live agent is rebuilt (and loopback base_urls no longer carry cloud auth), so requests actually go to the accepted backend instead of the stale startup one.
• fix(dash): detect rocm serve's default port in chat auto-detect #88 fixes discovery: detect_local_endpoint() only probed Lemonade :13305 and vLLM :8000, so a non-managed rocm serve instance (its own default :11435) was never found in the first place. It adds :11435 to the probe list and updates the two UI copy strings.

End to end you need both: #88 makes rocm serve discoverable, #81 makes an accepted endpoint get used.

Overlap is minimal — the shared files (llm.rs, ui/tabs/chat.rs) touch different functions/regions and don't conflict. The one spot to watch is app/mod.rs: #88's edit to the refresh_detect failure message sits a couple of lines above this PR's accept_detect_offer rewrite, so whichever merges second will need a trivial adjacency fixup (no semantic conflict).