fix(compress): refuse compressions that do not shrink the context

[Mukller]

fix(compress): refuse compressions that do not shrink the context

Closes #573

Problem

Across one 454-message session, repeated range compressions entered a
self-reinforcing loop: each new block re-absorbed the previous block's (bN)
placeholder plus a thin new tail of raw messages, and produced a summary larger
than the content it replaced. The on-disk summary grew monotonically to ~68k
tokens, 71 blocks were created, and 738,738 prune tokens were burned.

Two things allowed it:

1. No size guard at all. A compression that destroys the original content and
   replaces it with something bigger was accepted and persisted. The model was
   never told the compression was pointless, so it retried, and because each
   attempt wrapped the previous block again, the block grew every round.

2. The cost of a range was under-counted. selectionTokenCost did not exist;
   only the raw messages were considered. A b10..m0190 range looks almost free
   when what it actually absorbs is block 10's whole summary, which is precisely
   the range shape the runaway growth used.

Change

• selectionTokenCost(selection, messagesState) — raw message tokens in the range
  plus summaryTokens of every compressed block the range absorbs.
• assertCompressionShrinksContext(summaryTokens, inputTokens, boundaryLabel, idFormat) —
  throws when the summary is not smaller than the content it replaces, naming the
  boundary and telling the caller to widen the range or leave the content alone.
  Applied in both compress/range.ts and compress/message.ts, before
  applyCompressionState, so a refusal leaves no partial state.

The refusal is what breaks the loop: the model gets a real error instead of a
successful-but-useless compression, and the original content is still there.

The floor, and why it exists

The guard only engages at or above 2,000 input tokens. Below that it stays out
of the way entirely. Compressing three short messages into a slightly longer
summary is a normal, deliberate choice, and tokenizer noise on very small texts
makes the comparison unreliable — an early version of this guard with no floor
broke 17 existing tests that compress tiny fixtures.

The runaway growth being guarded against is orders of magnitude above that: the
smallest pathological block in the report was already ~1.6k tokens on the way to
~68k. tests/compression-size-guard.test.ts pins both sides of the floor.

Verification

tests/compression-size-guard.test.ts, seven cases. Five fail on the current
implementation.

• a range whose summary is bigger than its content is refused, and no block is
  created (asserted on state.prune.messages)
• a range with a genuine gain is still applied
• message mode applies the same guard and names the message id
• selectionTokenCost counts absorbed block summaries (1_000 + 40_000)
• the guard fires at equal and at worse-than-original, and not below the floor
• the boundary is rendered in the session's id format (@4..6@ for compact)
• a small range is left alone

Full suite 126 passing, tsc --noEmit clean, prettier --check clean.