sessions: capturing a live-session message reads the binding's whole external-source state

[ScriptedAlchemy]

Summary

Capturing one message on a live session reads the whole session's external-source object state. load_current_mutations (crates/tracedecay-rusqlite-runtime/src/repository/external_source.rs) selects every current object of the binding joined with its mutation history (SELECT history.mutation_json, ... FROM external_source_objects_v2 AS current LEFT JOIN external_source_mutations_v1 ... WHERE current.binding_id = ?1), and the same for external_source_projected_objects_v2. A transcript binding gains a current object per message, so each capture costs O(session length).

Evidence

Found while fixing #2607 (isolated test profile, the session_store_read_cost fixture: one live Codex session, 500-word title, one message per capture). Per-statement read attribution with a local SQLite trace scaffold, averaged over three single-message captures:

live session length	external_source_objects_v2 current-state read per capture	whole capture read per message
16 messages	~12 KB	~350 KB
128 messages	~107 KB	~750 KB

The drain and temporal refresh of the same messages stay within 1.13x over the same growth after #2607's fix, so capture is now the part of a streamed message's ingest that grows with the session.

Expected

Capturing k new messages reads O(k) external-source objects plus bounded binding state: look up only the objects the commit mutates instead of materializing the binding's full current state.

[ScriptedAlchemy]

#2777 (da62880) removes the O(session) capture read. The capture planner and the writer now load only the source objects a commit names, and the binding-wide scan in load_current_mutations is gone.

• Live session growth: over an 8× longer live session, per-message ingest reads (capture, drain and refresh) went from 1.53× on master to 1.15×. The test is session_store_read_cost::streamed_message_ingest_work_does_not_grow_with_the_live_session.
• Hotpath, built CLI, same profile and stream: load_current_mutations went from 10.9 ms to 0.087 ms per call, and capture_observations from 20.7 to 14.5 ms per message.

Leaving this open because the brief's acceptance is not fully met:

• Store growth. An 8× larger store, with the same live-session length in both windows, still grows per-message reads 1.30×, against the 1.2× target. The per-statement trace shows no remaining scan. The growth is one or two B-tree pages per point lookup, from cold reader transactions (about 11 per message in refresh) and writer cache-capacity misses. Closing it needs consolidated reader snapshots, not a cache raise.
• Whole-daemon bytes per message. These can't be measured cleanly yet. After a project opens, an idle daemon reads 11–15 MB/s from the backpressured history-ingest retry loop in sessions: backpressured history pass re-sweeps every transcript every ~0.5 s #2774, which swamps the stream windows on both master and this change.

[ScriptedAlchemy]

Re-measured after #2779 and #2786 (isolated hotpath daemon; 120 streamed messages per window, 183 ingested):

Store	Raw bytes per message	Net bytes per message
Base (about 7.6k messages)	2.48 MB / 2.05 MB	2.18 MB / 1.81 MB
8× (about 60.6k messages), before #2786	32.4 MB / 19.3 MB	32.0 MB / 19.05 MB
8× (about 60.6k messages), after #2786	5.05 MB / 3.11 MB	window 2: 2.82 MB

Whole-file Codex rereads and per-rollout git matcher spawns were the store-scaled cost, not index depth. #2786 removed them: scan_prior went from 17,600 calls to 0, and matcher_new from 17,693 calls to 0.

What remains is about 1.5× growth. Hot B-trees are 2–5 levels deep at the base store and gain at most one level at 8×, which would allow up to (d+1)/d, i.e. 1.25–1.5×. Two things keep me from attributing all of it to depth:

• page attribution in an in-crate probe showed WAL reads and external_source_retained_receipts_v1 growing faster than their depth;
• the Codex session_meta head is still re-read once per unchanged rollout per pass (Codex history pass re-reads session_meta of every unchanged rollout #2787).

I am not closing this issue, because remaining growth is not yet shown to be only index depth.