DIS-042: when cur has its OWN divergent commit, be patch <peer> then be post replays cur's stack ONTO the peer and silently drops cur's own committed bytes from the tree (first parent = peer, not cur — violates Invariant 2)

After DIS-038 fixed POST-015's silent-collapse, a DISTINCT divergent-case defect remains: when cur carries its own commit C forked off a shared base, absorbing a divergent peer T (be patch file://A?/A OR ?A!) then be post '#m' produces a commit whose single first parent is the peer T, with committer rebase <rebase@dogs> ts 0 — i.e. POST routes the absorb through GRAFRebase, replaying cur's stack onto T. The committed tree carries the peer's bytes but DROPS cur's own committed bytes (C's edit) even though they are still present on disk, so the worktree diverges from the committed tree and C's work is silently lost from history. This contradicts Invariants Invariant 2 ("the new commit's first parent is always cur's prior tip") and POST §"Commit assembly". Reproduced live (debug build, $HOME/tmp, hermetic). The non-divergent (FF) and same-base cases are correct; only a genuinely-divergent cur triggers it. See POST, PATCH, Invariants, Graf, CLAUDE.

Issues

The absorb-then-post commit-assembly takes the rebase-onto-peer path instead of a merge/commit on cur's tip.

Blockers

None for diagnosis; the fix is a POST commit-assembly decision (which is out of POST-015's silent-drop scope, hence this ticket).

Planned

Repro-first, then make absorb-then-post keep cur as first parent.

Evidence (live, debug build, hermetic $HOME/tmp)

DAG: base v0C(cur, BOF edit BLOCAL) and v0T(peer, EOF edit PEER). After be patch file://A?/A! the wt holds BOTH edits; be post '#absorbed' commits.