fix: support Codex remote compaction v2 for DeepSeek models

[skychentian]

Problem

When Codex triggers automatic context compaction (remote compaction v2) on a DeepSeek-bound session, DSCodex previously just renamed the model and forwarded the request unchanged. DeepSeek's Responses API answers with ordinary output items, but the Codex client requires exactly one compaction output item — so automatic compaction failed on every retry and the session got stuck (502 / reconnect loop).

Fix

The router now implements the compaction protocol for DeepSeek instead of forwarding the trigger raw:

1. Intercept: a DeepSeek-bound request containing compaction_trigger is detected; tools and the trigger are stripped.
2. Summarize: the same V4 Flash model is asked for a compact handoff summary (no tools, summary-only prompt; conversation content treated as material, not new instructions).
3. Seal: the summary is wrapped as a single synthetic compaction output item, encrypted with AES-256-GCM using a key derived from the stable router token, and streamed back before response.completed.
4. Restore: on later DeepSeek requests, only DSCodex-prefixed compaction items are decrypted inside the router and restored as assistant summary context.

Compaction never falls back to GPT (a GPT-sealed blob would be undecryptable across providers anyway), and the summary is never stored as plaintext in the rollout JSONL.

Tests

• New protocol tests cover the round trip: compaction request → exactly one compaction item → next request decrypts and restores the summary as readable context.
• Full suite: 61/62 pass. The single failure is a pre-existing Windows VBScript path assertion (mixed \\// separators) unrelated to this change.

Docs

README (zh/en) and AGENTS.md updated with the new compaction behavior and its boundaries.