fix: match nested blocks by any visible representation in range

[ranxianglei]

Follow-up to #119 (billion-context-pi#195).

Regression found in e2e

billion-context-pi e2e scenario 05-multiple-compressions fails on 0.0.38:
activeBlockCount === 1 — got 2. The second compression (m-ref range over the
whole visible history) no longer consumes the first block.

Root cause

When a block covers the session's first user message, prune keeps that one
raw (first-user exception) and inserts the rendered summary at the block's
earliest raw position — i.e. before the surviving raw. The summary index
then sits outside an m-ref range that still contains the raw.

#119's nested discovery used visibleBlockAnchor (summary-preferred) for range
membership, so the block was missed → not consumed → left active. Pre-0.0.36
code used raw-only anchors, which is why this geometry worked before.

Fix

New exported blockVisibleInRange(block, indexByMessageId, start, end): a
block participates in a range when any visible representation (rendered
summary OR earliest surviving raw) falls inside it. Used at both nested
discovery sites:

• resolveBoundaries initial scan (src/boundaries.ts)
• applySingleRange rescan after pair-boundary adjustment (src/compress.ts)

Anchor resolution for bN refs (visibleBlockAnchor) is unchanged.

Validation

• New regression test pins the exact geometry (block covers first user message;
  summary precedes surviving raw; m-ref range must consume it). Fails without
  the fix.
• 438/438 tests, typecheck clean, build OK.
• billion-context-pi: kernel dist overlaid → full e2e suite 5/5 PASS
  (05-multiple-compressions: blockCount=2, activeBlockCount=1, compressionCount=2).

Release note

0.0.38 (already published) does NOT contain this fix. Downstream release
branches (pi v0.1.46 / omp v0.3.2 / billion-context) should pin v0.0.39
once this lands.