fix(runtime-host): page oversized transcript Turns

[Sun-GLiang]

Summary

Allow Runtime Host transcript bootstrap to degrade oversized target Turn range metadata to null boundaries, preserving bounded pages and cursor-based continuation. Ordinary Turn and partial-edge Turn protection remains unchanged.

Fixes #4428

Verification

• npm run astryx:surface-inventory — pass
• npm run astryx:surface-inventory:test — 15/15 pass
• npm run lint — pass
• npm run format:check — pass
• npm run build:test — pass
• node --test packages/runtime-host/dist/__tests__/session-transcript-pager.test.js — 18/18 pass
• npm --workspace @maka/runtime-host run typecheck — pass
• npm run test:dist — all workspace tests pass
• git diff --check — pass

AI use

Select exactly one:

• No generative tool made a substantive contribution
• Generative tooling made a substantive contribution

Tool(s) and scope: OpenAI Codex — diagnosis, implementation, regression tests, CI investigation, and PR text.

Checklist

• Tests cover the change and fail without it
• Lint, format, typecheck and the affected suites pass locally

Does this PR entail a change in behavior?

• Yes — described under Summary above
• No

[Astro-Han]

Thanks — reviewed 073c4455. Approving; four P3s below, none blocking, all fine as follow-ups.

The problem is demonstrated without relying on the new tests. readRangeEdges throws once a single Turn passes SESSION_TRANSCRIPT_RANGE_MAX_MESSAGES (256) or SESSION_TRANSCRIPT_RANGE_MAX_BYTES (16 MiB), and createSessionTranscriptBootstrap maps any non-TranscriptOverlayCapacityError into persistence_failed / "Session transcript is unavailable" — which is the log in #4428 verbatim. Those thresholds are Runtime Host's own, so a user cannot avoid them, and a 257-message tool loop is an ordinary size. The throw arrived with #4244 two days before the report, so this is a reachable regression rather than a hypothetical.

I checked the three claims in the summary rather than taking them:

• Pages stay bounded. The bound never came from readRangeEdges — bootstrap reads through readDurablePage({ maxMessages: SESSION_TRANSCRIPT_RANGE_MAX_MESSAGES, … }) and continuations through continuationMessageLimit(position) with requirePageByteLimit capping maxBytes at 512 KB. readRangeEdges only trims a selection back to whole-Turn edges, so returning input.selected untouched leaves the reader's own limits in force.
• Cursor continuation survives. pageFromSelection signs the cursor from selected.next, and cursorRangeBoundarySequence is already null-valued elsewhere, so resolvePosition keeps walking. A 286-message single Turn pages as 256 + 30 with no repeats and no gap.
• null is inside the consumers' contract. Both production readers already handle it: session-subscription.ts:247 treats a null boundary as reachedBoundary = true, and all three sites in desktop-transcript-replica.ts were already written as page.protectedTurnSequence ?? …. And the degraded path returns at the 257th record, so it does not become a full scan.

"Fails without it" checks out — running the new test file against unmodified main gives 15 pass / 3 fail, and all three failures are the new cases hitting the target RangeError.

P3 — the second production change looks unreachable, and it leaves a dead throw carrying the same message. group[0] is a subset of input.selected, which is already bounded at ≤ 256 messages and ≤ 512 KB by requirePageByteLimit, so the groupStart === 0 branch cannot exceed 256 / 16 MiB; a target Turn over the limit has already returned at the earlier site. The three new cases all fail on main at the first site, and the second has no coverage. That doubles the production surface, and :423 still throws RangeError('Session transcript Turn range exceeds its capacity limit') — the identical string — so anyone grepping it will still read "oversized Turns throw", which is now wrong. Collapsing the limit check to the one authority in the scan loop lets both the second branch and that throw go, and the message disappears from the tree.

P3 — the running-Turn case duplicates the terminal-Turn one. Both use the same 286-message fixture and the former's assertions are a subset of the latter's; readRangeEdges never reads rootTurn, and the fixture reader ignores it too, so both land in the same return. #4428 asked for active-Turn coverage if the code path differs — it doesn't. Either drop it, or give it real activeAssistantStreams / overlay so it proves that degradation still holds once the overlay takes budget.

P3 — two assertions in the byte-bound case are tautological. With maxBytes at 512 KB and 600 KB messages, bootstrap can only return one truncated fragment, so fragments.length <= 256 and rawBytes <= 512 * 1024 hold under any implementation. The case earns its place as the only byte-bound coverage; assert.equal(fragments.length, 1) plus a continuation that retrieves the full message would make it say something.

P3 — worth naming what the degradation gives up. With protectedTurnSequence null, residentTurnKey groups this session under one Turn and #evictToBudget can't evict a protected key, so Desktop's resident set grows with the whole Turn rather than being capped by the Host's 256 / 16 MiB. It's bounded by that Turn, recovered by discard() on session switch, and before this change the session could not be opened at all — so the net is still an improvement. But "preserving bounded pages" is only half true, and the other half belongs in the summary with a pointer to #2913.

Evidence boundary: I read the pager against main, both production consumers of the boundary fields, the protocol limits, and the bootstrap error mapping, and ran the test file three ways (PR head 18/18, main 16/16, main production + PR tests 15/3). I did not exercise the real SQLite reader — the fixture ignores maxStoredBytes, so the byte path is verified against the fixture rather than storage — and I did not open a 286-message session in Desktop to confirm the error is gone.

---

AI-assisted review: drafted with Maka; I verified the boundary consumers, the continuation cursor, and the three-way test run against the branch source myself.