Greptile Summary

This PR fixes a bug where the TUI footer could get stuck in streaming after a non-local chat final arrived when activeChatRunId was already stale (pointed to a run that never had events in the current sessionRuns). The fix adds an allowStaleFooterRecovery optional flag to finalizeRun() — when set (for non-local runs), and when no tracked runs remain in sessionRuns after the finalized run is removed, the footer is force-recovered by nulling activeChatRunId and calling setActivityStatus. Two regression tests for the prior #53115 local-run-defer behavior are also added.

Confidence Score: 5/5

Safe to merge — targeted, well-tested fix with no P0/P1 issues found.

The sessionRuns.size === 0 check correctly evaluates after noteFinalizedRun removes the current run, so it reflects 'no other runs remain.' The concurrent-run test (line 505) still passes because a truly concurrent run keeps sessionRuns.size > 0. The allowStaleFooterRecovery: !isLocalRun guard preserves the existing #53115 defer behavior for local runs. All edge cases appear covered by the new and existing tests.

No files require special attention.

_{Reviews (1): Last reviewed commit: "fix(tui): recover footer state after sta..." | Re-trigger Greptile}

Closing this because the remaining blocker is an unrelated CI timeout, not a contained issue in the TUI change itself. I tried the low-cost recovery path first, but rerunning the failed workflow requires repository admin rights, so this is not something I can cleanly fix from the branch.