TUI: footer duplicates and “Working” status briefly disappears after interrupt + immediate resubmission

A proposed fix was submitted in this PR.

Fresh diagnosis against main at 536f86e5cc9ec1ff38457d099bf320b9d08eeeba: this is a cross-platform, terminal-independent pending-turn lifecycle bug. The original Linux/WezTerm environment is consistent with the shared code path involved.

What happens

1. The user interrupts an active turn and immediately submits another message. The TUI records that pending input should be sent after interruption through submit_pending_steers_after_interrupt.
2. When the interrupted turn completes, on_interrupted_turn calls finalize_turn. This clears the active lifecycle and makes the bottom pane idle.
3. The same interruption handler immediately resubmits the pending steer as a new turn.
4. The submission path sets user_turn_pending_start = true, correctly recording that work has been submitted but has not emitted TurnStarted.
5. update_task_running_state, however, derives the bottom-pane state only from an active turn, review mode, and MCP startup. It does not include the pending-start state.
6. The TUI therefore has user_turn_pending_start set while bottom_pane.is_task_running() remains false.
7. The gap ends only when TurnStarted invokes on_task_started.

The status header may already say Working, but the status row is not rendered because the bottom pane considers itself idle.

This also accounts for the footer artifact. The bottom pane temporarily loses the status row and contracts, moving the footer upward. When TurnStarted arrives, the row returns and the pane expands again. That height churn allows the previous and current footer rows to remain visible at different positions during the transition.

Why the state is fragile

Pending-start handling is split across several paths:

• User turns set pending state in the message-submission path.
• Compact, review, and user-shell commands set it in prepare_local_op_submission.
• Review separately forces the bottom pane into its running state in submit_op.
• prepare_local_op_submission runs before a direct channel send is known to have succeeded.
• AppEventSender::send logs and swallows enqueue failures, so callers cannot distinguish accepted dispatch from rejection.
• handle_turn_start_rejection finalizes shared turn state rather than releasing state owned specifically by the rejected attempt.

Required invariant

Once a start-producing operation is accepted by its local dispatch boundary, the TUI should remain task-running until either:

• the corresponding TurnStarted consumes the pending reservation, or
• that same dispatch attempt fails and rolls back its reservation.

A rejected attempt must not clear an older accepted pending start.

The task-running calculation should include pending-start state alongside active turns, review mode, and MCP startup. The same reservation lifecycle should cover UserTurn, Compact, Review, and RunUserShellCommand.

Transport side effects should occur only after local acceptance:

• For direct dispatch, reserve after submit_op successfully sends the command.
• For app-event dispatch, have enqueueing report success.
• Around the exact app-server start request, reserve before awaiting the request and roll back only that attempt's reservation if the request fails.
• Apply interrupt cleanup only after its dispatch has been accepted in the AppEvent::CodexOp path.

Suggested regression coverage

A deterministic test does not need timing or a real terminal:

• Submit a turn successfully but do not emit TurnStarted.
• Assert that pending-start and bottom-pane task-running states are both true.
• Render a snapshot containing one Working row and one footer.
• Emit TurnStarted and verify that the bottom-pane height does not change.
• Cover failed direct enqueue, app-server rejection, and a failed second attempt while an older reservation remains active.