CODE-051: the TRI mark survives its lane — lost tri runs are never rebuilt

Now: OPEN
Sev: HIGH
Rep: ///bee
Ask: gritzko
Rev: ///bee#8cb69a0
See: BEE-071
See: BEE-061

Input

Context

index/lindex.js:229:PS-233,295: the TRI round's watermark lives in the lite3 lane while its postings live in *.tri.idx, and nothing cross-checks them. Confirmed on a clone of git.git carrying its real be/: rm .git/be/*.tri.idx then bee index prints "up to date", bee grep reftable_stack_destroy answers nothing, and every later run repeats it; only rm -rf <gitdir>/be (a full 81k-commit re-derive) recovers. BEE-061 gave bringUp the same treatment for the lite3 mark. Found in the 2026-09-18 index review.

Goals

Read a cheap liveness probe of the tri lane beside the mark — any *.tri.idx present, or tix.count > 0 — and treat the mark as absent when the lane is empty, the way index/index.js:1113:Wt checks the tip's CPAR row beside its mark.

WIP

TODOs

[x] repro: tri runs removed, grep silent, index says up to date
[x] tridex mark honoured only with a live lane

Design decisions

The probe is one io.readdir of <gitdir>/be for a name ending in .tri.idx (tridex.laneLive), not tix.count: it costs no lane open, so the O(1) no-op stays O(1).
A dead lane drops the mark from the DIFF BASE too, not just from the up-to-date test. A base of a lying mark names the tip, so descend(tip, tip) yields nothing and the round would re-mark the tip having minted not one row back.
The mark val's reserved nibble now says which mark it is: 1 = the round honestly minted nothing (a tree with no 3-byte RON64 run), believed with no file beside it, and 0 = rows on disk, believed only while a .tri.idx is there. That is what BEE-071's "mark only over runs" guard lacked — it read test/cts's honestly empty lane as swept.
The nibble is read the safe way round: an index written before this change carries 0, so it is re-derived once and re-marked, which is what the git.git case in Context needs.