Fix: stop looping auto-compaction when it cannot restore context headroom

Fixes 48827

Problem

When a session's irreducible context (system prompt + retained recent tail) exceeds the model's usable window (context - min(limit.output, OUTPUT_TOKEN_MAX)), auto-compaction can never bring the session back under the overflow threshold. The session loop then compacts after every step forever: compaction → synthetic "Continue if you have next steps…" → overflowing step → compaction → …

Concretely observed with cerebras/qwen-3.8-27b (context 65,536 → usable 33,536) on a session whose post-compaction floor was ~43k tokens: an unattended compaction↔build ping-pong running 20+ cycles per minute, each cycle issuing a full-context API call, until it tripped the provider's TPM rate limit. The user sees a spinner and no error; meanwhile the auto-continue keeps the agent executing tool calls autonomously on every cycle.

Fix

New no-progress guard, judged by outcome rather than count:

• SessionCompaction.failedAutoCompactions(msgs, over) — pure helper: walks the session history and counts the trailing run of automatic compactions whose first finished non-summary successor step still overflows the model's usable window. A real user turn, a manual compaction, or a successful compaction resets the run.

• SessionCompaction.failedStreak({ sessionID, model }) — service method that applies the helper to the full (unfiltered, chronological) session history using the same isOverflow inputs as the trigger (cfg + outputTokenMax aware).

• Both auto-compaction trigger sites in session/prompt.ts (the start-of-iteration isOverflow check and the processor's "compact" outcome) now consult the streak before creating another compaction. When it reaches MAX_FAILED_AUTO_COMPACTIONS (2), the loop stops and publishes a ContextOverflowError:

  Session still exceeds the model's usable context window after 2 automatic compactions. Start a new session or switch to a model with a larger context window.

Judging by the first successor step is what avoids false positives: legitimate flows that overflow again only after pulling in a new large tool result have a healthy first post-compaction step, so they compact normally. Because the streak is computed from persisted history (not loop-local state), the guard still trips promptly even if the session loop was restarted in between (app relaunch).

Validation

• Unit tests: 9 new cases for failedAutoCompactions (consecutive failures, synthetic-continue messages don't reset, real user turns reset, manual compactions ignored, summary steps skipped as successors, no-successor edge, later-overflow-doesn't-mark-good-compaction) plus a DB-backed failedStreak test building a real ping-pong history. Full package suite: 3590 pass / 0 fail, tsgo --noEmit clean.
• Repro scenario: the guard turns the observed infinite loop in the issue into 2 bounded compaction cycles followed by a clear, actionable error.