[matt2e]

Follow-up to #3071, which made a channel longer than one page wait for the unread store's repair before placing the "New messages" line and held the channel's own reading meanwhile. This addresses the three review threads left open when that PR merged.

Problem

1. A failed or overflowed repair held reading forever (Kalvin, Wes). The hold keyed on sampled alone. A repair that failed, overflowed its evidence budget, or was abandoned by a dropped connection or an access change left sampled unset with requested already true, so ensure() started nothing. Once later live evidence made the store observed again, the timeline held reading until some unrelated repair happened to succeed.
2. Any read row counted as the witness above the line (kazemek21). A row read only by its own msg: receipt (dwell short of the bottom) says nothing about the rows above it, so a short repair sample could place the line below a row whose predecessors were still unread.
3. buzz-help overstated the hold (Wes's review summary). It said the divider settles before the channel marks anything read, as if that applied to every visit.

Fix

1. Channel snapshots now report sampling while a repair that can set sampled is reading, about to restart, or not yet requested. The timeline holds reading only while it is set; otherwise the visit settles with no line and reading resumes, including when the channel is entered after such a repair already ended. sampling stays set across the gap between a repair settling and its restart (repairAgain), so the hold does not flicker.
2. attention() reports prefixRead when a channel-wide read reaches the row: the channel's read frontier, the activity: catch-up mark for an ordinary top-level message, or the retention floor. Only such a row lets the line sit below it.
3. docs/buzz-help.md scopes the wait to the history check and says reading resumes if that check fails; it also says the line is absent when the rows above were only read one by one. docs/unread.md and the code comments record both behaviours and the remaining residual.

Testing

Run with Hermit via bin/pnpm, on b76ba40 (parent 5cf1713, current main).

Scope	Result
ChannelTimeline.restore.test.tsx, unread.test.ts, unread-startup.test.ts, use-reading.test.ts, use-reading.dm.test.ts	5 files, 422 passed
vitest related on unread.ts and ChannelTimeline.tsx	240 files, 7,143 passed (run on the parent c4b8ecd before the fast-forward to 5cf1713; that commit touches only Codex/MCP files)
tsc --noEmit, Biome, git diff --check	clean
Chromium tests/browser/new-message-boundary.spec.mjs	4 passed, including the 25-message channel
Not run	WebKit journey, the full suite, the native app, manual testing

Each new regression test fails without its fix:

• Reverting the timeline's sampling release fails 3 tests: the failed-repair case where the store becomes observed again before any dwell, and entry after an already-failed and an already-overflowed repair.
• Reverting the prefixRead check fails the receipt-only witness case.
• Dropping the repairAgain term fails the store test's restart-gap assertion.
• Removing sampling and prefixRead from the store fails the 3 store tests, including the startup test that walks failure, retry and overflow against a live session.

Known limits

• A channel read part-way by scrolling (rows read only by their own msg: marks) now shows no line on return. The line needs a row above it that a channel-wide read reached.
• Unread mentions, broadcasts, broadcast replies and marked-unread messages above the loaded window remain the documented residual: catch-up's activity: mark never reads them, so a short sample can still hide one.
• In the startup test harness, the first queried roster revokes access and abandons an in-flight repair without restarting it. That store behaviour predates this change; sampling now reports it correctly. Possible follow-up, not changed here.

🤖 Generated with Claude Code