Everything since 93f66d4 has been carried in the working tree. This lands it:

- The cut campaign: 208 files retired (benchmarks and the router experiments, klbr-bench, the
old LCM store surface, the starter's own root docs), -180,096 lines against +22,583. By its own
census: 110,545 -> 62,750 physical lines, -43.2%.
- The runtime work whose files were never added: peers, orientations, prompt headers, skills,
attempt budget, migrations 010..016, and the Python workspace/peer/orientation surface with
the skills that document it.
- The daemon half of the windowed transcript: a bounded `subscribe` that opens after the
session's context fold (`lcm_frontier`, `drained_through_seq`), `earliest_seq`/`fold_seq` on
the replay frames, and a `history` request that pages backwards. The console half, and the
frames the two sides share, are in their own commits.

One commit rather than three because the halves are not separable: the modified files
reference modules that exist only in the new files (klbr-runtime/src/{peer,frontier,
prompt_header,skills}.rs, the 010..016 migrations), so any split leaves a commit that does not
build. The tree as one unit is verified: `cargo test -p klbr-ipc -p klbr-daemon` green, the
store suite green including its new bounds/page test, the console's own suite green.

Also ignored now: /target-parent (123,424 build-artifact paths that `git status` was showing)
and /.releases (behavior releases published by Release::publish at runtime).

The window opens after the session's context fold, so the daemon now says which record that fold drained
through and the console mentions it at the window's edge — while the window is above it. A reader who has
paged back past the fold is reading the prefix itself, and there is nothing summarized about what they are
looking at, so the note goes.

The window request is `after_seq: 0` with a `limit` rather than `after_seq: null`: a daemon that does not
know about windows ignores the limit and replays the session, which is what it did before, so the request
cannot leave a client against an older daemon with an empty transcript. The fixture reports the fold and
carries it on pages, and its folds are `lcm_frontier` records with the payload the runtime actually
writes.

`src/lib/protocol-v2.test.ts` replays the exact frames `klbr-ipc/src/v2.rs`'s `window_frames` suite pins,
through this console's parser and client. Two implementations of one contract drift in silence otherwise:
a renamed field is an empty session on one side with nothing red on the other.

A transcript that starts somewhere other than the session's beginning has to say so, in three places.
The first row is now the window's own edge: a control that asks the daemon for the records behind it, and
that names the compaction when the window opens on one, because that fold is the whole reason the
transcript starts there. A turn is numbered by its place in the session — the sequence of its opening
record — rather than by its rank in the window, which would number turn 361 as "#1" and tell the reader
the session began where their window does. And a turn the window cut in half makes no summary claims at
all: a count of the records that happen to be loaded is not a summary of the turn, and the failure that
is above the edge would not be in it.

Pressing load-earlier lands the reader at the top of the page that just arrived rather than leaving them
still, since records arriving above a viewport that does not move look like nothing happened.

It also fixes the follow, which the bigger sessions exposed: the list adjusts the scroll itself when a
row measures, after the app's own hold has written the end and from the size that row had before it
measured. The correction left the reader a row short of the end, and the scroll event it caused read as
the reader leaving — so the follow disarmed and the transcript never caught up with itself. Measured at
400 turns: 93px short, permanently. The end is now written twice per size, once after the list has had
its turn in the frame.

The cache existed to make a reload cheap, and it could not: a 4800-record transcript is ~10 MB against a
5 MB sessionStorage quota, so the biggest sessions it was written for were the ones it failed on. It is
gone, along with the remembered cursor and the diagnostics snapshot that were only there to avoid
replaying records it held, and the client now asks for what it can hold: `subscribe` with
`after_seq: null` and a `limit` is a window request, and the daemon answers with the newest window of at
most that many records, anchored at its own last compaction, reporting its range and its floor in
`sync_started` and `sync_completed`.

`{ type: "history", before_seq, limit }` asks for the records behind a loaded window; the answer is the
same replay shape, its records prepend into the timeline where their sequence puts them, and the live
cursor does not move for them. Deduplication is a set of seen sequences instead of a scan of the
transcript per record, which is what makes a retried or overlapping page idempotent. A daemon that says
nothing about its floor offers no paging, so a client against today's daemon degrades to what it does
now rather than to a button that does nothing.

The fixture serves the same contract, with a compaction every forty turns of the bulk session, so the
behaviour is reachable in a browser: at 400 turns the console opens on 481 records instead of 4809.

computeInputOutcomes scanned the transcript once per input, and it runs on every timeline change:
quadratic, and at 4800 records the largest single cost left in the console (26% + 13% + 12% of sampled
main-thread time). It is now one walk that gathers each turn's evidence as it finds the segments, it
lives in the data layer where it can be tested, and a differential test pins it to the algorithm it
replaced. An Intl.DateTimeFormat was also constructed per rendered row per render (8% of main-thread
time at 4800 records); it is built once.

One pass reads each record twice whatever the length; the old scan read 2, 52, 102, 199, 398 times per
record as the transcript doubled.

1440 records: 4.0s -> 1.1s. 4800 records: 34.3s -> 5.5s (from 120.3s before either change).

Writing the whole transcript to sessionStorage on every event made ingesting a session quadratic:
1440 records cost 2880 writes and 4.5 GB of string traffic, and the view took 21.7s to fill. A write
now waits for the stream to pause (or CACHE_MAX_WAIT_MS, whichever comes first) and for the page
going away, and the cursor is written by that same flush, after the records it covers, so a reload
can never resume from a cursor the cached records do not hold.

1440 records: 21.7s -> 4.0s, 2880 writes -> 2. 4800 records: 120.3s -> 34.3s, 50 GB -> 21 MB.