Fork session sends stale compaction tail_start_id, causing context overflow #24781

Description

After Session.fork copies messages into a new session, CompactionPart.tail_start_id still points at message ids from the parent session. MessageV2.filterCompacted compares tail_start_id to ids in the fork; it never matches, so the full pre-compaction history is included in the model prompt. That often triggers context_length_exceeded (e.g. on the next compaction or chat turn).

Steps to reproduce

1. Use a long session that has run compaction with a non-empty tail_start_id.
2. Fork the session (UI or API).
3. Continue chatting or trigger compaction — provider may return context length errors, or token usage spikes vs. the parent session.

Expected

Forked session should behave like the parent w.r.t. compacted history (same effective tail / same filterCompacted length for the same copied messages).

Actual

tail_start_id remains the old id; filterCompacted does not stop at the tail, so too much context is sent.

Regressed when tail_start_id was added for "keep recent turns" compaction (~2026-04-10); fork already remapped assistant parentID but not compaction tail_start_id.