fix(cli): defer threshold compaction during tool loops

[marius-kilocode]

Configured compaction thresholds can currently fire after a provider step while a tool sequence is still active. That lets an economic threshold interrupt a plan such as grep -> read -> apply_patch -> bash, replacing the active prompt with a compaction summary before the remaining validation tool runs.

The preflight path already measures the complete outgoing request and skips the configured economic threshold during tool continuations. The post-step path was inconsistent: it reused the threshold-aware isOverflow() cap after every provider step. This change makes that post-step check safety-only, comparing usage against the usable context limit. Configured threshold_percent behavior remains in preflight for normal request boundaries, and hard context-limit recovery is unchanged.

The regression was reproduced in the isolated harness with threshold_percent: 10: after apply_patch, Kilo compacted, issued summary/continuation requests, and omitted the expected bash test. The matching baseline completed the full tool sequence. The reproduction intentionally used 10%, not the current global 100% configuration.

The branch also removes the previously investigated Kilo prompt-cache-key change. Cloud already derives the production prompt_cache_key from X-KILOCODE-TASKID, so that client-side change is not part of this fix.

Changed paths are limited to the post-step overflow behavior, its focused tests, and the CLI changeset.

Validation:

• bun test test/provider/transform.test.ts test/kilocode/session-overflow.test.ts: 342 passed
• bun run typecheck: passed
• bun run script/check-opencode-annotations.ts --worktree: passed
• git diff --check: passed