MEM-008: GRAFRebase per-iteration BASS scratch never rewound (graf/REBASE.c)

Now
DONE

The rebase replay loop invokes the heavy carving helpers (tm_merge_trees, tm_merge_blob, GRAFPatchId) with plain assignment instead of call()/try(), so ABC_BASS is never snapshot-restored between iterations; each commit (and each tree-recursion level / divergent leaf) permanently bumps the arena by hundreds of KB to tens of MB, growing unbounded over chains up to REBASE_PATH_MAX=4096 until a_carve returns NOROOM and the rebase aborts. The goal is to rewind BASS around each iteration's scratch.

Issues

Carving helpers called directly, defeating the arena-rewind discipline; leak survives into sniff/POST.c.

Blockers

None. GRAFPatchId returns u64 (not ok64), so it needs explicit mark/rewind, not call().

Planned

Snapshot-restore BASS per iteration; keep hoisted buffers outside the marked region.