The gate caught it on its first run: the region walk answered the box correctly
five times over — the seek and the membership test were right — but the batch
re-served the same five records forever, because the cursor never skipped.
The cause is a one-word difference between the two existing walk paths, and it
was mine. `v3_enum` positions itself with `at = first + cursor` and so does not
need `Batch.seen` to skip; the packed walk has no index to reposition and relies
on `seen` instead, which is why it initialises `seen: 0`. My two region paths
re-seek to the span's foot every batch — there is no `first + cursor` for a box,
because a span holds records that are *not* returned, so the index position of
the cursor-th match is not arithmetic — and I had set `seen: cursor`, which
disables the skip and re-serves the span from its foot forever.
The fix is `seen: 0`, and the gate now shows why the trap matters: an unaligned
box [3,3,3]-[10,10,10] answers five records, and the record at (2,7,7) — outside
the box but inside the span — is examined and rejected, not returned.