fix: pr-bug-scan validated finding from #4669

[buf0-bot]

Automated fix-PR from pr-bug-scan for parent #4669.

Fixer status: FIXED_WITH_CODE_PROOF
Summary: Decay per-pane synchronizedForegroundOutputActive closure flag after 1s without an end marker; blocks the latch-stuck path that pinned later foreground writes on the scheduler 250ms hold.
Blocked proof link: src/renderer/src/components/terminal-pane/pty-connection.ts:1860-1868
Typecheck: skipped

Proof (from validator)

• C1 — proof_type: code_analysis
  • trigger: Windows ConPTY TUI emits \x1b[?2026h in a foreground chunk and then is killed/crashes/never emits \x1b[?2026l. After the safety timer drains the held bytes, any later foreground PTY chunk arrives.
  • observable: Every foreground PTY write on the affected pane is delayed by up to 250 ms (safety timer) before reaching xterm — keystroke echo and TUI/shell output appear in 250 ms-delayed bursts. If foreground writes keep arriving faster than 250 ms apart, the safety timer never fires and output is held until the PTY goes quiet for 250 ms.
  • path:
    • src/renderer/src/components/terminal-pane/pty-connection.ts:486 declares let synchronizedForegroundOutputActive = false per pty-connection (per-pane closure)
    • src/renderer/src/components/terminal-pane/pty-connection.ts:432-437 shouldSynchronizedOutputRemainActive returns wasActive unchanged when neither marker appears in the chunk — no decay
    • src/renderer/src/components/terminal-pane/pty-connection.ts:1860-1868 sets nextSynchronizedForegroundOutputActive = shouldSynchronizedOutputRemainActive(data, synchronizedForegroundOutputActive) then assigns it back to the closure variable; once true with an unmatched start, it stays true on every later chunk that lacks markers
    • src/renderer/src/components/terminal-pane/pty-connection.ts:1886 passes holdForeground: synchronizedForegroundOutput && nextSynchronizedForegroundOutputActive to writeTerminalOutput
    • src/renderer/src/lib/pane-manager/pane-terminal-output-scheduler.ts:528-547 hold path enqueues, sets foregroundHold = true, and calls scheduleForegroundHoldSafety which delays drain by FOREGROUND_HOLD_SAFETY_DELAY_MS (250 ms)

---

Generated by pr-bug-scan (proof-machine architecture). Human approval required before merge.

[pullfrog]

✅ No new issues found.

Reviewed changes — adds a 1-second timeout on the per-pane synchronized-output latch so a TUI that emits \x1b[?2026h and then dies without the matching end marker cannot pin every subsequent foreground write on the scheduler's 250 ms hold path for the lifetime of the pane.

• Add SYNCHRONIZED_FOREGROUND_OUTPUT_ACTIVE_MAX_MS (1000 ms) — ceiling on the per-pane DEC 2026 latch; longer than any legitimate synchronized frame, short enough to recover within ~1 s.
• Track synchronizedForegroundOutputActiveSince — Date.now() timestamp set on false→true transition, cleared on true→false (or decay).
• Force-decay in writePtyOutputToXterm — after computing nextSynchronizedForegroundOutputActive, if it's still active and has exceeded the max, set it to false so holdForeground routes the chunk normally.

  ^{｜ View workflow run ｜ Using DeepSeek Pro (free via Pullfrog for OSS) ｜ 𝕏}