test(storage): thread fixture refs across ops inside one parity transaction #912

run_transaction in crates/nostream-storage/tests/parity.rs allocates a fresh HashMap for refs on every nested op, while the top-level script threads one map across the ops it runs:

match run_op(backend, Client::Transaction(&transaction), nested, &mut HashMap::new())

refs is how the fixture refers to a value a previous op produced — an outbox.enqueue records its message id under the event type, and a later outbox.mark_delivered looks it up. Inside one transaction the lookup always misses, so the harness cannot express "enqueue, then mark the same row delivered, in one transaction", which is exactly the sequential write the outbox has to survive.

What this needs

• Thread the caller's refs into run_transaction and through the loop, matching what the top-level script does at parity.rs:1020.
• A fixture transaction that enqueues and marks delivered in one group, plus the existing rollback probe.
• A negative control recorded: with the per-op map restored, the new fixture must fail; with the fix it must pass.

Found by an external reviewer after the branch merged (#910, 827558a); it does not affect the shipped backend, only the harness's ability to prove it.