CODE-049: REV-PARS edges resolve through the newest blob, not the parent commit

Now: OPEN
Sev: HIGH
Rep: ///bee
Ask: gritzko
Rev: ///bee#8cb69a0
See: BEE-005
See: LITE-006

Input

Context

index/index.js:1197:Wt resolves a parent rev through st.byPB, a (path, blob) -> NEWEST rev map, regardless of ancestry. A content revert on one branch makes the other branch's rev the "parent": on a 4-commit fixture, rev 3 (commit c3 off c0, whose only parent is rev 0) recorded pars=[2], a rev on the sibling branch. index/dag.js:131:~c floorRev walks these edges, so a bee diff over such a path folds from the wrong floor and shows spurious hunks. Found in the 2026-09-18 index review.

Goals

Repro: the revert fixture, assert PARS names rev 0. Take the parent's rev off the parent COMMIT — the walk has just sealed it — via a (path_hl, commit) -> rev memo for the frontier, falling back to byPB only for an unindexed parent.

Constraints

No format change; PARS rows already sealed stay (suspect edges are tolerated).

WIP

Design decisions

The memo is st.byPC, (path_hl<<60|commit_hl) -> rev, filled both by emit and by loadPath's CMMT span, so a parent indexed in an EARLIER run answers off the rows, not byPB.
emit takes the commit's parent hashlets; descend already keeps pblobs parent-aligned, so slot i is parent i.

TODOs

[v] repro: revert on a sibling branch steals the PARS edge
[v] frontier memo (phl, commit) -> rev feeds PARS

Blockers and bummers

A parent that did NOT amend P has no rev of it, so the byPB fallback still runs and can name a sibling's revert rev there. Closing that needs a CPAR climb per parent per changed path (what repsOf does at read time) — a cost ruling for gritzko, not a one-liner.