fix: index an applyWrites batch in op order master
zds applied every delete before every create, so a same-key create+delete in one batch left the record row present while the MST had dropped it — the tree mutates in op order. The reference PDS walks its writes in one ordered loop (actor-store/repo/transactor.ts indexWrites) and tranquil resolves each delete against the running tree, so zds was the outlier and could reach a state neither implementation produces. Blob refs move from a trailing pass matched by URI to a span captured per record at staging time. Matching by URI inside the ordered loop would have been O(records x refs), and applyWrites caps the body at 5MB but not the op count. Benchmarked interleaved against the pre-fix binary, 10 runs each: 197.0 vs 207.1 ops/s with stdev ~7, i.e. no measurable change. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>