CODE-054: kv sweep never lexes a file that has no block but an old mtime

Now: OPEN
Sev: MED
Rep: ///bee
Ask: gritzko
Rev: ///bee#8cb69a0
See: BEE-024
See: BEE-025

Input

Context

index/kv.js:340:9B: the mtime test is the ONLY gate on re-lexing, so a file with NO block whose mtime is below the mark is skipped forever and invisible to find. Confirmed twice: mv todo/AAA-001.mkd todo/AAA-007.mkd (a rename keeps the mtime — the journal's routine thin->fat TKT-1.mkd -> TKT-1/README.mkd move) leaves the new path at rows=0 on that run and every later one; and after a path_hl collision clears (kv.js:314:9B killBlock'd both files) neither ever comes back. cp -p, tar -x and rsync -a restores behave the same, and view/todo.js:775:i4 drops such a file from the board once any lane clause narrows. Found in the 2026-09-18 index review.

Goals

Lex unconditionally when blocks.get(t.phl) is absent or its wt is not this worktree; the mark is an optimisation for KNOWN blocks only.

WIP

Design decisions

The gate is now block-first: the mtime mark only speaks for a block this worktree already owns, so an absent block (a rename, a restore) and a foreign one always lex. INDEXES.mkd:181:6K carries the ruling.

TODOs

[v] repro: rename with preserved mtime, file never indexed
[v] missing block forces the lex
[v] the post-collision block comes back once the clash clears