CLI: transport status should be visible in /status

I implemented a narrow version of this locally for the CLI/TUI /status card.

Shape of the change:

• Add an app-server transport display value derived from AppServerTarget.
• Carry that value through ChatWidget state, the same way runtime provider/remote connection status is carried today.
• Render a new /status row named Transport near Model provider.

The labels are intentionally about the app-server connection layer rather than provider billing/config:

embedded app-server
local daemon over Unix socket
local daemon over WebSocket
remote app-server over Unix socket
remote app-server over WebSocket

That preserves the existing Remote row for the sanitized address/version, while making the active transport visible even when the CLI is using the embedded app-server and there is no remote address to show.

Validation run locally in WSL:

cargo test -p codex-tui remote_connection_status_value_formats_display_value --lib
cargo test -p codex-tui status_snapshot_uses_default_reasoning_when_config_empty --lib
cargo test -p codex-tui status_model_provider_uses_bedrock_runtime_base_url_and_gates_usage_link --lib
cargo test -p codex-tui status::tests --lib

Result: all passed; the filtered status::tests run covered 44 tests. The snapshot change is just the expected added Transport: local daemon over Unix socket line in the /status output.

I think the remote transport varies between WebSocket (seems to be the default) and HTTPS (I guess long poll, in case of fallback).

A narrow Transport row is useful. The next thing I would avoid is making "connected" imply "healthy and controllable."

If this grows beyond the first display value, the fields that help debugging are:

• transport kind
• endpoint or sanitized target
• local owner: embedded, daemon, remote, or unknown
• pid/source when local
• last heartbeat or last successful probe
• fallback state, e.g. websocket -> HTTPS long-poll

That keeps /status useful for the common failure case: the CLI has a transport, but it is connected to the wrong listener, a stale daemon, or a fallback path with different behavior.

---

_Generated with ax._