Improve remote compaction pre-trimming and overflow retry behavior

[cbusillo]

Current Status

Remote compaction overflow retry behavior was partially fixed in #78.

Before #78, context-overflow during remote compaction could drop one old item and retry repeatedly, up to 32 failed remote compaction attempts. That matched the dogfood symptom where remote compaction appeared to fail many times and could burn rate limit before falling back.

#78 changed that path to:

• Trim to a bounded recent-history window once.
• Retry remote compaction once with that reduced input.
• If it still overflows, apply emergency compaction fallback instead of continuing remote attempts.

Remaining Investigation

The local fix/auto-compact-overflow-resilience stash still contains related but unmerged ideas. Inspect these separately before carrying anything forward:

• Sanitize CompactionSummary / ContextCompaction items before compaction so encrypted checkpoint payloads are replaced with placeholders.
• Propagate inline remote compaction errors through streaming call sites instead of silently returning empty history.
• Decide whether any additional pre-trimming is needed before the first remote compaction request, beyond the one-retry overflow cap from Cap remote compact overflow retries #78.

Non-Goals

Do not apply the old stash wholesale. It also contains unrelated babysit-pr, .github/github.json, and harness assertion changes that belong in separate reviews.

Acceptance Criteria

• Each remaining compaction behavior has a clear keep/drop/rewrite verdict.
• Any kept behavior lands in a focused PR with targeted tests.
• No path can issue repeated remote compaction overflow attempts comparable to the old 32-attempt behavior.
• Any error propagation change is verified not to lose the active conversation or hide emergency fallback results.