fix(terminal): drain deferred output without a wake event

[Lint111]

Summary

Fixes terminal output that could remain queued indefinitely after a large final response.

flushPendingWrites() writes one mode-specific frame budget and requeues the remainder. Previously the scheduled flag stayed set while that function ran, so its attempt to schedule the next yield was ignored. The remainder appeared only when unrelated output arrived later, which looked like truncated agent responses or passive shell commands waking only after user activity.

Change

• centralizes terminal flush scheduling in _scheduleTerminalWriteFlush()
• clears writeFrameScheduled immediately before a flush runs
• lets a large flush enqueue its own successor until pendingWrites is empty
• reuses the same scheduler after flicker-buffer release
• updates the anti-flicker documentation to match xterm.js 6 and the current mode-aware frame budgets

Validation

• test/terminal-flush-budget.test.ts: 7 tests passed
• new regression drains a 96 KB final Codex batch as three 32 KB writes without another terminal event
• npm run check:frontend-syntax
• npm run typecheck
• npm run build
• Prettier and staged diff checks

Scope

This PR does not change terminal streaming protocols, input handling, session lifecycle, viewport ownership, or mobile controls.

[Ark0N]

Hi Lior, closing this one as part of a cleanup of the seventeen PRs currently open from you. The full explanation is in #173, and I would rather you read that one than this note, because it is the honest version and it is not a dismissal of your work.

The short form: sixteen PRs opened in a single day, roughly 42,000 added lines in total, landing mostly on the same few files (nine touch app.js, eight touch terminal-ui.js), with five already conflicting against master and none carrying CI results. I cannot review that at the standard this codebase needs, and merging it at a lower standard would be worse than not merging it.

Going forward, please keep no more than three open PRs at a time, each one a single behavior change that stands on its own, with a test that fails on master and passes with the fix. #214 and #215, merged today, are good models.

If this particular change fixes something that genuinely annoys you in daily use, it is a good candidate to be the first one you reopen on its own, rebased on current master. I will review it properly.

Thanks for the effort you put in, and sorry to close it this way.