Find and fix three persistence event-gap leak sites

[pathscale]

Based on deps/arctic-0.1.11, not on master. The seven files here do not overlap the three that branch changes, but this was written and tested against its dependency bump, so it is stacked rather than rebased. Merge that one first.

The event gap

BatchOperation::validate refuses an event stream with a hole in it. A hole is normally transient: the operation carrying the missing id has been produced but not yet batched. A hole that survives the whole deferral budget is not transient, and the stall message could not tell the two cases apart. It reported the range and nothing else:

persistence stalled on primary index event gap: last applied Id(1439),
next available Id(1455) (attempt 9)

Two very different bugs produce that line. Either an id was assigned by the index and its event was dropped instead of queued, so nothing will ever deliver it and the stream is permanently gapped, or the operation was queued and batch collection keeps assembling batches that exclude it.

Distinguishing them needs a record of what was queued. Assignment happens inside the index, which this crate cannot hook, but every event reaching persistence passes through Queue, so an id present in the stream and absent from the ledger was assigned and never queued. That is the leak signature and it is what gap_report reports.

Producers are named by std::panic::Location. That is why push_at takes the caller location, and why the old push and push_many wrappers are deleted rather than left in place: push_at's own documentation warns that calling push loses exactly the location the ledger exists to record, so keeping the wrapper is keeping a trap.

The ledger found three leak sites, all in generated persisted query code, and the second commit fixes all three: the NotFound arm of the update insert path, and the two bare res? sites in gen_process_diffs_remove_on_index and after delete_row_cdc. Each now builds an Acknowledge carrying the orphaned events and applies it before propagating, which is what the rollback arms already did.

The events are moved into the acknowledge rather than cloned, and that is load-bearing. Cloning does not compile: the events type is still an inference variable there, pinned only by the op.extend_secondary_key_events call further down, so method resolution for .clone() has nothing to resolve against. It fails as an E0282 against the worktable! invocation with no inner span.

The write failures are not forcible through the public API, so both regression assertions pin the emitted tokens and check the acknowledge comes before the return or the extend, not merely that one appears. The in-memory generator has the same two NotFound arms and is deliberately untouched: no persistence stream sits behind them.

The formatting job

scripts/ci-local.sh runs cargo fmt --all --check as its first step and CI did not, so the local script was stricter than CI rather than equal to it. Measured before adding the job: the tree already passes, exit 0, no diffs. The job is green as written.

The change log

The log carried beta.18 and beta.19 and nothing before them. Backfilled to 0.3.10 from this repository's own history.

Correction carried in docs/TODO.md

The congee crossbeam-epoch port was already done, in congee-wt 0.4.4, and the TODO was wrong about both the state and the nature of it. It was a design change rather than a rename: per-tree Domain, batched retires, guard provenance checked. The new Guard is !Send and tree-scoped, which constrains future callers.

Verification

cargo fmt --all --check                                 exit 0
cargo test --workspace --all-targets                    1086 passed, 0 failed
cargo clippy --workspace --all-targets -- -D warnings    exit 0

[pathscale]

CI does not cover this PR. .github/workflows/rust.yml triggers only on pull_request: branches: [master], and this one is based on deps/arctic-0.1.11, so no checks run against it. That is a gap in its own right: every stacked PR in this repository is unverified by CI until its base merges. I have not changed the trigger, because widening it means every stacked branch runs the full matrix and that is a policy call rather than a fix.

Verified locally instead, on the merge state of this branch:

cargo fmt --all --check                                  exit 0
cargo test --workspace --all-targets                     1086 passed, 0 failed
cargo clippy --workspace --all-targets -- -D warnings     exit 0

The new formatting job in the first commit is included in that and is green.

Note also that the formatting job this PR adds will not run on this PR, for the same reason.

[pathscale]

Folded into #102, which now carries this work plus the tokio::fs removal and tunable page stride, rebased linear with no merge commit. WorkTable carries one PR for this chain.