[Question]: Should CoPaw support pluggable context compaction strategies for long-running workflows?

## Question or topic

Should CoPaw support a pluggable / customizable context compaction strategy for long-running, tool-
heavy workflows?

## Context

We are building an AIOps-style operator on top of CoPaw. In our case, a single workflow can run for
hours and involve 300+ tool calls. At that scale, context compaction becomes a core architecture issue
rather than just a context-window optimization.

What we need to preserve is not only recent chat continuity, but also deterministic workflow state,
such as:

- current stage
- validated inputs
- blocking reasons
- pending next actions
- artifact references

By contrast, some content can be aggressively compacted:

- verbose tool results
- repetitive browser observations
- long intermediate outputs

From reading the current code, the existing compaction flow seems to be:

- `MemoryCompactionHook` decides when to compact and which messages to compact
- actual compaction is delegated to the memory manager / ReMeLight backend
- current config mainly controls thresholds and reserve ratios, but not semantic preservation rules

## Tried so far

We reviewed several related issues / PRs, and the community concerns seem consistent:

- recent tool-heavy context can be lost: #947, #2378
- compaction can inject hallucinated content: #1437, #2092
- preserved context is not transparent after compaction: #2047
- stronger fallback / recovery behavior is needed: #2356
- the project is already moving toward pluggable memory backends: #2307, #2308

This makes me wonder whether compaction should also become more pluggable.

## Discussion point

Would it make sense to support a strategy-style compaction pipeline, for example:

1. select what must be preserved
2. extract structured state from compactable history
3. summarize the remaining narrative content

The goal would be to let different scenarios define different compaction semantics, instead of relying
only on generic summarization.

## Questions

1. Is the current compaction design mainly optimized for assistant/chat continuity, or also for
workflow/state continuity?
2. Would a pluggable compaction strategy be considered in scope for CoPaw?
3. If yes, where would the preferred extension point be:
- hook layer
- memory manager layer
- ReMe integration layer
- separate strategy interface

If this direction makes sense, I can refine it into a more concrete proposal.