fix(dash): prefer a local chat server over the cloud default at startup

[michaelroy-amd]

Summary

• Startup only single-probed DEFAULT_CHAT_BASE_URL (:8000) and then fell back to the ChatGPT cloud OAuth flow, even though the manual 'd' detect action already knew how to find a local engine on any of its well-known ports (Lemonade :13305, vLLM :8000, rocm serve :11435) plus the managed-services registry.
• A server running on any port other than :8000 (e.g. a rocm serve default install) was invisible at startup, so the user landed in the cloud login flow instead of talking to their already-running local server.

Root cause

event_loop()'s startup block (crates/rocm-dash-tui/src/app/mod.rs) called detect_managed_chat() (registry-only) and then a single probe_endpoint() against one URL, instead of reusing chat::detect_local_chat() — the same registry-first + 3-port-probe + model-fetch detection the in-app 'd' action already used.

Fix

• Startup now calls detect_local_chat() in the same branch that previously called detect_managed_chat() (gated on "no explicit chat_url/env URL configured" — CLI/config precedence is untouched).
• Parallelized llm::detect_local_endpoint()'s port probe with std::thread::scope so a cold start with nothing listening still costs one PROBE_TIMEOUT (~300ms) instead of three sequential probes (~900ms worst case), keeping startup latency bounded.

Coordination with #97

Unmerged PR #97 (volen) also touches this startup branch, adding model discovery inside resolve_llm_config's own fallback path when chat_model is None. This change is conflict-minimal: it only swaps detect_managed_chat for detect_local_chat and leaves the resolve_llm_config(...) call itself untouched, so a rebase either direction should be a clean textual merge.

Relates to EAI-7347.

Test plan

• cargo build -p rocm-dash-tui
• cargo clippy -p rocm-dash-tui --all-targets --all-features (clean under -D warnings)
• cargo test -p rocm-dash-tui -- --test-threads=1 (all green, incl. 3 new tests)
• New test: llm::tests::detect_local_endpoint_prefers_lemonade_when_multiple_reachable — priority order preserved under parallel probing
• New test: llm::tests::detect_local_endpoint_bounded_latency_when_nothing_listening — latency regression guard
• New test: app::chat::tests::detect_local_chat_prefers_local_server_over_no_endpoint — startup-preference behavior (a listener on rocm serve's default port is detected with no executor/registry available)

[rominf]

LGTM. Startup now reuses the full detect_local_chat path (registry + parallel well-known-port probe) so a local server correctly wins over the cloud default:

• when detection finds a server, detected.is_some() short-circuits resolve_llm_config → local wins;
• when none exists, detection_ran && detected.is_none() sets probe_ok = false and falls through to OAuth without a redundant re-probe (VLLM_ENDPOINT and DEFAULT_CHAT_BASE_URL resolve to the same loopback:8000 target);
• the api-key gate in should_detect_local_chat correctly prevents detection's keyless config from dropping a configured credential.

The parallel probe preserves priority order via the order-preserving handles Vec + find_map, panicked probe threads are swallowed as false, and there are no hot-path unwraps. SPDX headers present; removed detect_managed_chat import is safe (now called transitively).

Approving.

[volen-silo]

🔴 Automated review · pr-review-watcher · f64bb40

Summary

At TUI startup, this swaps the old detect_managed_chat + single :8000 probe for the full detect_local_chat (registry-first + parallel 3-port probe + model fetch), so a local server on a non-default well-known port (e.g. rocm serve's :11435) is now preferred over the ChatGPT cloud default; probing is parallelized to keep cold-start latency at ~1×PROBE_TIMEOUT. Verdict: Approve — no correctness regressions found. Verified: cargo build, cargo test -- --test-threads=1 (all green), and cargo clippy --all-targets --all-features all pass on f64bb40; I traced every startup branch (server-present, no-server→OAuth fallback, chat_api_key set, explicit url/env) and confirmed no behavior regression — a server on :8000 is still found (via VLLM_ENDPOINT), the OAuth fallback still fires, config precedence and key-safety are preserved, and the thread::scope spawn-all-then-join with in-order find_map correctly preserves probe priority. Blocking: 0 · Non-blocking: 4.

🚫 Blocking (must fix before merge)

None.

Non-blocking

• llm.rs:510 — detect_local_endpoint_bounded_latency_when_nothing_listening does not actually guard the regression it claims. On closed loopback ports connect_timeout returns ECONNREFUSED in ~microseconds, not after PROBE_TIMEOUT, so a revert to sequential probing still completes in <1ms — far under the 4×(1.2s) threshold (verified empirically). The guard only bites when connects genuinely time out (dropped SYNs), which loopback doesn't produce. Consider asserting order/behavior instead of wall-clock, or drop the timing assertion.
• llm.rs:223 — the removed detect_local_endpoint_probes_rocm_serve_default_port test left detect_local_endpoint()'s actual candidate wiring (esp. ROCM_SERVE_ENDPOINT as 3rd fallback) untested; all new probe_first_reachable_* tests use synthetic ephemeral URLs and the sole live caller discards its result. A dropped/reordered/mistyped candidate constant would go uncaught.
• app/mod.rs:1583-1662 — the new startup decision logic (detection_ran → probe_ok short-circuit → no_key_no_endpoint → OAuth-vs-local branch) is the actual fix but is untested glue; only the isolated pure helpers are covered. Extracting probe_ok/no_key_no_endpoint into pure testable fns would let this be unit-tested without the full terminal harness.
• app/chat.rs:439 — test name detect_local_chat_prefers_local_server_over_no_endpoint overstates scope: it only proves the probe return value is wired into the config (its own doc-comment says so), not the startup preference the name implies. Rename to match (e.g. ..._wires_probed_endpoint_through).