fix(desktop): report session override provider in session info

[luntion]

Summary

Fix Desktop/TUI session.info so it reports the user-facing per-session provider override instead of the internal resolved runtime provider when a session was created or switched through a named custom provider.

For named custom providers, the live agent may expose agent.provider == "custom" because that is the resolved runtime/billing class. Desktop treats session.info.provider as sticky composer state. If it stores the internal "custom" value, a later session can pair the selected model with the wrong provider group and fail with provider-side model-not-supported errors.

This change makes session.info prefer session["model_override"]["provider"] when it still matches the live agent model, falling back to agent.provider for normal/built-in providers and older sessions.

Why

Desktop model selection sends both model and provider. However, after the live agent is built, session.info can overwrite the Desktop provider state with the runtime provider class instead of the original provider slug.

This is especially visible when multiple named custom providers expose overlapping model IDs. The model name remains correct, but the next request can be routed to a different provider group.

Changes

• Add _session_info_provider() helper in tui_gateway/server.py.
• Prefer the current session's model_override.provider when it describes the live model.
• Keep the previous fallback to agent.provider.
• Add regression coverage for:
  • named custom provider override survives agent.provider == "custom"
  • stale overrides are ignored when the live model no longer matches

Related

Refs #50151

This is complementary to #50151. That PR guards Desktop against unsafe provider payloads. This PR fixes the backend payload source so session.info sends the user-facing session provider when available.

Testing

./.venv/Scripts/python.exe -m pytest tests/test_tui_gateway_server.py -k "session_info_prefers_session_model_override_provider_for_custom_runtime or session_info_ignores_stale_model_override_provider" -q
# 2 passed, 299 deselected

./.venv/Scripts/python.exe -m pytest tests/test_tui_gateway_server.py -k "session_info" -q
# 4 passed, 297 deselected

git diff --check
./.venv/Scripts/python.exe -m py_compile tui_gateway/server.py tests/test_tui_gateway_server.py

Note: scripts/run_tests.sh was not used on this Windows checkout because it expects a POSIX-style .venv/bin or venv/bin virtualenv, while this local venv is Windows-style .venv/Scripts.

[tonydwb]

Code Review Summary

Verdict: Approved

Clean fix: adds _session_info_provider() helper that prefers the per-session model_override provider over agent.provider for the user-facing provider identity. This prevents the Desktop picker's internal custom value from leaking into sticky composer state. Test coverage covers both the override-preferred and stale-override-fallback cases.

---

Reviewed by Hermes Agent

[teknium1]

Thanks for the focused backend fix. The premise remains present on current main: tui_gateway/server.py:3373 publishes the runtime agent.provider, and Desktop persists the incoming payload through setCurrentProvider at apps/desktop/src/app/session/hooks/use-message-stream/gateway-event.ts:125-127. The proposed source is appropriate: session.create stores the selected provider in session["model_override"] at tui_gateway/server.py:5212-5216, and the PR falls back to the runtime value when that override no longer matches the live model.

The related #50151 maintainer comment identifies backend emission of the canonical user-facing identity as the correct boundary; this change follows that direction. The target _session_info region is unchanged from the PR base on current main, so this should be mechanically salvageable.

Automated hermes-sweeper review.