[FEATURE] Allow Claude to self-initiate context compaction

Problem

Currently, context compaction is triggered automatically by the system when context usage reaches a threshold. Claude has no ability to initiate compaction proactively. This creates a real workflow problem:

Claude cannot prepare for compaction. When working on complex multi-step tasks, Claude often needs to:

1. Write critical state to handoff files before context is compressed
2. Complete a logical checkpoint (e.g., finish a code review cycle, update documentation)
3. Ensure all in-flight reasoning has been persisted to disk

Because compaction timing is unpredictable, Claude frequently loses important context mid-task — details like naming conventions, file numbering schemes, prior decisions, and subtle constraints that were discussed but not yet written to files.

Real-world impact

In a session today, after an automatic compaction, Claude:

• Forgot a test log naming convention that was documented in a memory file (but not re-read after compaction)
• Created files with wrong names 3 times before the user corrected it
• Had to be reminded of context that was discussed extensively pre-compaction

The user had established a file-based persistence system (handoff files, session state, memory files) specifically to survive compaction. But because Claude can't control when compaction happens, there's always a gap between "last file write" and "compaction trigger" where in-context reasoning is lost.

Proposed solution

Add a tool or command that allows Claude to self-initiate compaction at a chosen moment. For example:

/compact   (user-initiated, already exists)

New: allow Claude to call a Compact tool (or similar mechanism) that:

1. Triggers compaction immediately
2. Allows Claude to prepare — write all critical state to files before compacting
3. Returns control to Claude post-compaction, with a clean context that can re-read the files it just wrote

This is analogous to how a programmer manually commits before switching branches, rather than having an auto-save overwrite at random intervals.

Why this matters more than it seems

The 75% auto-compact threshold is a blunt instrument. It optimizes for "don't run out of context" but not for "don't lose important reasoning." Claude with self-compact ability would:

• Persist before compress: Write handoff → compact → re-read handoff (clean recovery)
• Choose natural breakpoints: Compact after completing a logical unit of work, not mid-reasoning
• Reduce post-compact confusion: Fewer "I lost track of what we were doing" moments
• Enable longer autonomous workflows: Complex multi-step tasks (code review cycles, multi-file refactors) could run more reliably

Alternatives considered

• Pre-compact hooks (PostToolUse at 75%): Already implemented by users, but can only remind Claude to write files — can't delay or control compaction timing
• More aggressive file persistence: Helps, but adds overhead to every step. Claude shouldn't need to write every intermediate thought to disk "just in case"
• Larger context windows: Delays the problem but doesn't solve it. Complex sessions will always eventually need compaction

Additional context

Related issues: #19872 (param separation), #26488 (partial compaction), #24867 (compaction blocks work). This proposal is complementary — it's about agency over timing, not compaction mechanics.