fix(runtime-host): respect transcript continuation boundaries

[Dante-dan]

Summary

Keep durable transcript continuations within the Turn boundary encoded in their cursor. Durable message sequences are sparse, so their numeric distance can overestimate the remaining message count and let a continuation pull in the next Turn, exceeding the client's 256-message range limit.

Clip the continuation at its original boundary and resume the next page at the first deferred message. Preserve fragmented-message continuation, normal Turn protection, and the existing protocol limits and wire format.

Fixes #5183

Verification

• Added real pager/client regressions for adjacent 161/134-message Turns in both directions and owner/shared projections, a Turn exactly at 256 messages, and a partially read message deferred to the next range.
• Pager suite: 23 tests passed. The adjacent-Turn and exact-cap regressions fail with the reported RangeError without the fix.
• Runtime Host suite: 1849 passed, 12 skipped.
• npm run lint, npm run format:check, npm run build, and npm run typecheck passed.
• npx knip --workspace apps/desktop and npx knip --workspace packages/ui passed.

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, validation, 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]

Approving. This is the right fix at the owner: the range never crosses the Turn boundary the cursor encodes, and that rule lives in the pager, where the cursor meets the storage read. Thanks for tracing it — the diagnosis in #5183 was mine and it was wrong about where the budget went; readRangeEdges does include the selected page. The real cause is what you found: continuationMessageLimit estimates count from sequence distance while durable sequences advance by a stride of 8, so the estimate is ~8× high and the continuation eats the next Turn. Reading the trim point: it always lands at a Turn end and the first deferred row opens the next Turn, so no consumer sees a torn Turn, and the few over-boundary rows main used to return are gone too.

I approved the workflow run, so CI is going now. Three non-blocking notes, none of which should hold the merge:

• firstOmitted.kind !== 'durable' cannot be reached — the findIndex predicate already requires durable.
• readSharedDurablePage still stops on record.sequence === rangeBoundarySequence itself, so the boundary trim now has two implementations; the shared half of the new matrix likely passes on main already. Fine to leave and collapse later.
• The durable branch's continuationMessageLimit no longer carries correctness after the trim, only read size; worth a one-line note so the estimate is not mistaken for a guard again.