v0.8.69: Make provider idle-timeout status line thresholded instead of persistent noise

[Hmbown]

Problem

During a normal DeepSeek V4 Pro wait, the footer/status line repeatedly shows copy like waiting for deepseek deepseek-v4-pro, 3s/300s idle timeout. This is useful as a diagnostic when a stream is actually suspicious, but it is too noisy as a default every-turn status.

Screenshot context from 2026-06-12: while the release-smoke agent is just waiting on the provider, the bottom line spends visible space on the idle-timeout countdown. Hunter called out that we should not show the idle-timeout detail every time.

Proposed fix

Keep the idle timeout internally tracked, but make the visible UI calmer:

• normal wait: show concise provider/model state, e.g. waiting for deepseek deepseek-v4-pro
• thresholded diagnostic: show idle seconds only after a meaningful quiet period or when near timeout
• warning/error state: show idle budget once it becomes actionable
• detail view/log: keep full idle timeout budget available for debugging

Acceptance criteria

• Normal provider waits do not always display Ns/300s idle timeout in the primary footer/status line.
• Idle timeout detail appears when the stream is actually stale, near timeout, or explicitly expanded.
• Provider/model identity remains visible during waits.
• Existing structured provider-wait incident logs keep full idle/budget detail.
• Tests cover fresh wait, thresholded wait, near-timeout wait, timeout/error state, and compact/narrow footer rendering.

Related

• 报错：Stream stalled: no data received for 90s, closing stream。 #1060 tracks stream-stall behavior.
• v0.8.59: Sub-agent fanout planning can leave the TUI stuck in provider wait with no backpressure or recovery #3095 added provider-wait observability for v0.8.59; this issue narrows the default visible copy so observability does not become footer noise.

[Hmbown]

Additional status-surface note from 2026-06-12 testing: the same policy should apply to repeated repoll, thinking, and waiting copy that keeps restating the active mode, for example yolo mode. Mode should remain visible in stable mode indicators and mode-change events, but should not be repeated in every wait or repoll line unless it is actionable, has changed, or the user has expanded diagnostics.

Additional acceptance coverage:

• normal waiting and repolled-thinking states suppress repeated mode copy in the primary footer/status line
• mode-change events still surface once and remain discoverable in the stable mode indicator
• expanded/status detail still exposes full mode, provider, and timer context for debugging