CODE-025: status/quad ahead-behind should read the graf.idx count cache

Now: OPEN
Sev: LOW

Deps: none — the accelerating index EXISTS in be/ today. shared/graf.js (GRAF-001) maintains a persistent lazy ahead/behind COUNT cache over *.graf.idx, and views/work/work.js already consumes it (grafFor); status/ quad bypass it and recompute from scratch. Perf, not dedup. See graf.

Input

Context

quad.js:224 calls dag.aheadBehind(k, base, track), which builds the COMPLETE ancestor-node map of BOTH sides (dag.js:76-96) — O(history) parent-BFS + parseCommit per node — on EVERY status (the default view).
work.js:130-155 opens the shard's graf ahbeh cache ONCE per shard and reads counts index-first; status/quad never touch it, so the same divergence is recomputed by full walk each time.

Goals

Short-circuit the divergence VERDICT (eq / ahead==0 / behind==0) via the graf.open count cache; keep the full walk only where row DETAIL is needed.

Constraints

Behavior-identical counts; the graf cache SATURATES at 0xFFFFF ("at least") — treat a saturated count as "many", never as an exact tally. be/ JS only.

WIP

Design decisions

Reuse work.js's grafFor(repo) shape (open once per shard, null on no keeper / graf.open throw) rather than a second opener.

TODOs

wire quad/status quadOf to graf.open(shardDir).aheadBehind counts
use counts for the divergence verdict; fall back to dag.aheadBehind only when the row list is actually rendered
measure status latency before/after on a deep-history shard

Blockers and bummers

Full ahead/behind ROW lists still need a walk today; the commitindex (GRAF-002, tracked in CODE-026) would accelerate that remaining case.

Outcome

Not started. Suggested commit: CODE-025: status ahead-behind via graf.idx count cache.