DIS-041: `be get`/`patch` FF-weave bails with `graf err` and leaves the file UNMERGED when the commits aren't indexed — the correct fallback is to INDEX the commits and RETRY

Now: DONE

When a store-backed worktree that is BEHIND trunk is fast-forwarded (be get '?'), files that diverged on both sides need a 3-way weave. If the relevant commit DAG is not indexed, the weave drops to build_tip_weave_tunable's no-history fallback (graf/GET.c:537-548), which stamps each side's blob with its own tip hashlet so the two sides share NO baseline birth-ids → WEAVEApply matches nothing → GRAFFAIL (sniff/GET.c:748), and sniff prints merge failed … (graf err) — leaving wt content untouched, i.e. the file is left UNMERGED. The only correct fallback is to index the commits and RETRY the weave — never bail, never silently return ours. See PATCH, POST, Graf.

Input

Context

LIVE REPRO (now on disk — the earlier investigation said this transient "is no longer on disk / cannot be driven through be"): FF the BE-004 store-backed worktree ~/todo/BE-004-new (cloned behind trunk) onto current trunk → be get '?' → merge failed for bro/BRO.c (graf err) and graf/BLAME.c (graf err) — leaving wt content untouched. Reproducible on demand from any behind-worktree FF where both sides touched a file.
The (void)-ignored GRAFIndexFromTips guard (sniff/PATCH.c:1857, comment: "Without this the merge silently returns ours's bytes") is the smoking gun — the index step exists but its failure is swallowed.

Goals

The FF/weave path INDEXES the needed commits (the tips' ancestry) and RETRIES, so a behind-worktree FF on a real divergence actually MERGES.
No silent fallbacks: an un-indexed/empty-side weave must index+retry or propagate a hard error — never "leave wt untouched", never return ours.
Acceptance = the real be get '?' operation merges the divergent files (demonstrated on a live behind-worktree), not "tests green".

Constraints

Do NOT touch the weave ENGINE on a disjoint-edit premise — that is DISPROVEN (below). The fix is in the verb/index layer.

WIP

Design decisions

RETRACTED (unproven, was BS): the prior conclusion "the graf err is a verb-layer base/target SELECTION failure" is withdrawn — it was asserted without a live repro. Diagnose from the repro now available, not theory.
PROVEN, keep: the graf weave ENGINE merges disjoint edits byte-identical to git merge-file (the frozen SUBS-019 trio, 135584 B, clean via GRAFMerge3Bytes/GRAFMergeWtFile/GRAFMergeWtFileTunable). So the engine is correct; the bug is the verb dropping to the un-indexed fallback instead of indexing + retrying.

TODOs

Repro-first: a hermetic small store + behind-worktree FF that triggers graf err (regression test, e.g. extend graf/test/MERGEWT01.c).
Make the weave path index the commits and RETRY when history is absent (build_tip_weave_tunable / GRAFIndexFromTips); propagate index failure (drop the (void)), never leave-untouched / return-ours.
Prove be get '?' on a real behind-worktree MERGES the divergent files.

Blockers and bummers

Currently blocks landing BE-004 (its FF hits this); BE-004 stays unmerged until the FF-weave self-heals (index+retry) — NO hand-pick reconcile.

DIS-041: be get/patch FF-weave bails with graf err and leaves the file UNMERGED when the commits aren't indexed — the correct fallback is to INDEX the commits and RETRY