[ZouR-Ma]

Problem

Users reported that once the context approaches the window limit, every task becomes very slow, sometimes stalling for 20-30 minutes.

Reproduction against the real gateway with the real CLI (40+ requests, about 20M input tokens) isolated three separate problems:

1. Slow near the limit. At 930K context, every prompt is preceded by a maintenance request carrying about 975K tokens (roughly 30s), and the task request still needs 26s to its first token. The same command took 7.6s at 60K context and 62s at 930K.
2. Hard failures. With a large Chinese tool output at the end of the history, prompt size was undercounted by 2.45x, so the host believed it had not reached the threshold and sent the request unchanged; it exceeded the gateway limit and came back as The input you provided is invalid [code=30003]. That wording matches no overflow rule, so the run ended with no compaction and no retry. 5 of 16 real runs failed this way (an earlier batch failed 10 of 13).
3. Stalls. The client only gives up after 300s with no bytes at all, and keep-alives keep resetting that timer; one request in the logs hung for 19.5 minutes.

The reproduction also surfaced an existing bug: when the newest message alone exceeds keepRecentTokens and is a tool result, no cut point qualifies, so the whole history is kept, nothing is summarized, and automatic compaction silently does nothing. The first acceptance round passed 9/9 only because the corrected output reservation happened to fit, not because compaction ran.

Changes

Commit	Scope
feat(providers)	Estimate prompt size from UTF-8 bytes; classify the gateway's unnamed 400 as overflow when size evidence supports it; bound provider streams by event idleness
fix(compaction)	Apply byte estimates to every estimator and to summary sizing; cut-point fallback (matching upstream pi); reduce and retry a summary rejected with the unnamed 400; allow CLM calibration below 1
fix(compaction)	Route the unnamed 400 into the existing compact-and-retry-once path at session level
feat(compaction)	Default to native summary compaction with CLM opt-in; install the watchdog and retry.provider.streamIdleTimeoutMs
docs(compaction)	Documentation, CHANGELOG, and the offline reproduction harness

Two related value changes: the default compaction.triggerRatio moves from 0.9 to 0.85 (worst-case tolerance for estimation error grows from about 53K to 72K tokens), and compaction.autoClm.coldMaxPrefillTokens (default 262144) skips a cold CLM maintenance request in favour of native compaction.

Explicit clm-v1 and lightweight-v1 settings keep their behaviour; /clm on and --context-projection clm-v1 still enable CLM.

Measured on the real gateway (same scripts, model deepseek-v4.1-flash-api)

Scenario	Before	After
Chinese tail, default mode	2 of 3 failed	2/2 succeeded, about 21s
Chinese tail, native mode	2 of 3 failed (and never compacted)	2/2 succeeded, 21-26s
880K with no trustworthy usage	1 of 3 failed	2/2 succeeded, about 16s
930K, cold cache	47-72s	16.3s
60K baseline	7.6s	3.6s

Verification

• tsgo --noEmit and biome pass.
• providers 531, agent-core 566, coding-agent 638 across the 25 compaction-related files, plus 11 CLI tests.
• The pre-existing failures are unrelated to this change (6 in settings-manager, regressions/2781, 8337, scripts/release-notification all fail without this branch as well).
• The watchdog was verified against the gateway: with streamIdleTimeoutMs=2000, a 600K-token request was cut at the stall and resent by the retry policy.

Known gaps

• The end-to-end watchdog case in test/stream-idle-watchdog.test.ts is skipped: a provider registered through an extension in that harness does not pass through the sdk stream function (noted in the test). The watchdog itself is covered by its own unit tests.
• Pruning oversized old tool output before compaction (the deepseek-harness pruner approach) is not implemented.
• The reproduction scripts and evidence bundle (session JSONL, per-run reports) are provided separately and are not part of this PR.