perf(tui): stop walking the whole item store to list or open a thread

[gaord]

Summary

Opening a thread in the GUI is a sidebar click that took 1.3s warm / 6.7s cold on a 140-thread store (61,441 item files, 294MB) before the conversation appeared, and every second of it was one directory read. An item's filename carries only the item id, so the only way to find the items of the turns being opened is to read every item record and throw away all but the ~272 a median thread holds. Reading harder is not available either: sixteen concurrent cat streams over those 61k files finish in 3.6s against 2.1s for one, so the cost is the per-file syscall, not the bytes it moves.

Both reads on that path are now bounded by what the client asked for.

• The thread list reads each row's preview out of the row's own newest turn. item_ids is append-ordered and a turn's newest message is the last message item it appended (what follows it is a status, reasoning, file-change or tool record), so the walk ends within a handful of files per row: 165 item files for a page of 100, against 58,048 for the store-wide pass it replaces. A turn whose record predates item_ids still goes through that pass, collected for the whole page so the scan runs once rather than once per turn.
• Opening a thread reads the items directory once per store and answers from that map after. The map is built from that same walk, so it holds exactly what the walk held — including the items attach_item_to_turn deliberately leaves out of a settled turn's item_ids, which the rebuild paths read out of the directory anyway — and every item write keeps it current. A write that races the walk is recorded and drained into the published map; a write with no walk running records nothing, because its file is already on disk for the next walk to find. Both readers of one turn's items come off it: get_thread_detail and the fork preparation whose items the transcript rebuild consumes.

Measured on that store, both builds over identical clones:

	before	after
open a thread	1.33–6.34s	0.025–0.059s
thread list (/v1/threads/summary?limit=100)	1.27s	0.031s

One deliberate cost. The Runtime API warms the index while it starts, in the background, so the first open after a restart does not pay the walk either. That is a store read during launch, where the read used to happen once per thread opened. It is off the request path and the second half of RuntimeThreadStore::ensure_item_index is what a lazy first read would call, so say the word if you would rather pay it on the first open instead.

No-Issue: performance defect found by measuring a local store; nothing on file covers it.

Testing

macOS aarch64, with RUST_MIN_STACK=16MiB exported as scripts/dev-test.sh and CI do.

• cargo fmt --all -- --check — clean.

• cargo clippy -p codewhale-tui --all-targets --all-features --locked -- -D warnings -A clippy::uninlined_format_args -A clippy::too_many_arguments -A clippy::unnecessary_map_or — clean. That is the CI invocation limited to the crate this touches; a first run caught five lints in the new tests, all fixed.

• cargo check --workspace --all-features --locked — clean, so nothing outside the crate sees a broken shape.

• cargo test --workspace --all-features --locked — not run locally. The TUI lib suite alone ends red on this machine for reasons that predate this branch, and I would rather name them than tick the box:

  • tui::app::tests::app_new_detects_missing_api_key_with_default_config and tui::widgets::tests::ascii_safe_tier_covers_whole_rendered_surfaces fail identically on a stashed tree (this machine has an API key configured and renders CJK); proven by stashing this branch's changes and rerunning both.
  • runtime_threads::tests::host_goal_loop_kickoff_arms_one_continuation_and_parks_at_engine_cap and the two runtime_api::tests::compatibility_stream_* tests fail under a saturated parallel run and pass in isolation (test result: ok. 3 passed; 0 failed) — both were failing this way before this branch existed. cargo test -p codewhale-tui --lib --locked here reports 13436 passed; 5 failed / 13434 passed; 7 failed across two runs, i.e. the set moves with load.

• The tests this change owns, run alone:

  • runtime_threads::tests::list_items_for_turns_map_reads_the_items_directory_once_per_store
  • runtime_threads::tests::a_warmed_store_opens_a_thread_without_reading_the_items_directory
  • runtime_threads::tests::item_reads_include_items_a_turn_never_registered
  • runtime_threads::tests::an_item_written_while_the_index_is_being_built_is_published_once

  test result: ok. 4 passed; 0 failed.

• The regression guard was proved to bite. Restoring the pre-change read (a directory walk inside item_ids_for_turns) makes three of those tests fail — a later read must come off the index, not the directory: left: 12, right: 0 — and they pass again once it is reverted.

• Output equality with the previous build. Over identical clones, eight old threads' GET /v1/threads/{id} responses are byte-identical except latest_seq (each engine's own event cursor), and for six more, the item count, set and order match exactly. One early mismatch was traced to the live store being written between the two clones — the item files themselves differ.

• Also adjusted: thread_summary_listing_never_walks_the_items_directory asserted the items directory is read exactly once per page; it now asserts zero item files are read by directory walk, which is the stronger guarantee the preview read gives.

Checklist

• This PR adds a new layer/module/abstraction — it names or deletes the layer it replaces
• Updated docs or comments as needed
• Added or updated tests where relevant
• Verified TUI behavior manually if UI changes — no TUI surface changes here
• Harvested/co-authored credit uses a GitHub numeric noreply address — no co-authors

[devin-ai-integration]

Devin Review found 4 potential issues.