Record history rebuilds each patch entry from scratch, so listing a record's history costs n² audit reads #3569

Problem

getHistoryOfRecord, getHistory, read_audit_log and superseded subscription replay rebuild every patch entry on its own, through getRecordAtTime (resources/crdt.ts). Each call walks back from the live record to the entry, and a field whose value it cannot recover by reversal triggers a second walk forward from the record's last full put. Listing a record's history therefore costs about n² audit reads for n patches. A single recent snapshot of a record with a long patch-only history costs n reads.

Fields that take the forward walk: plain fields set by a newer patch (already the case on main), and, after the fix for the #1413 absent-field residue (branch fix/history-absent-fields-at-time), add-only counters whose reversed value is 0 or that have a fractional delta. Those walks are what makes the value exact: 0 cannot be told apart from "absent before the add established it", and float reversal leaves a residue.

Measured on that branch, with the box under load (audit-read counts are exact): one snapshot behind the head costs n+2 audit reads, about 12–15 ms at n=1000 and 45–86 ms at n=5000 on RocksDB. getHistoryOfRecord on 5000 patches takes 143–175 s on LMDB.

Suggested direction

• History listings: replay each record forward once, oldest first, carrying the folded state across entries, instead of rebuilding every entry from the live record.
• Single snapshots: settle the unknown keys walking backward from the entry, and stop once each one hits a put, a delete, or a plain set, instead of always replaying from the last put.

Review-Deferral: 6148b771cf8b67ff severity=minor category=performance

_{🤖 Generated by Claude Opus 5.5 (Claude Code dev-agent); posted via @kriszyp.}