Raised audit floor makes nearby historical reads eagerly scan older retained rows #4293

Closing review of #3504 found an eager prefix scan in resources/crdt.ts:390-395. Before trying a nearby state above the reported audit floor, reconstructAtTimestamp scans every retained entry below that floor. Native append order can differ from timestamp order, so replacing it with the first yielded key would reintroduce a confirmed false-absence bug. Investigate a lazy lower-bound probe while preserving the lowest actual retained key.

Measured on Node26.2.0/RocksDB2.14.0, one sample per variant with50,000 retained filler rows below a raised floor and target put+patch above it. Current a4b0e86:128.840ms wall/239.141ms processCPU,6native ranges including1prefix scan; pre-bound ancestor3d3a165 control:2.192ms/8.122CPU,5ranges/no prefix. Both returned{id:a,n:2}. This is a measured regression, not data corruption. The control uses the same native DB/fixture and temporarily substitutes only compiled crdt code, restored afterward.

A clean nonexact memo miss in the same fixture measured128.797ms/210.511CPU,7ranges/1prefix versus0.934ms/3.921CPU,6ranges/no prefix in the control; its wall cost is dominated by the same prefix scan. These internal helper measurements do not establish a public nonexact timestamp API.

Keep complete matching-origin frames, out-of-order retained keys and the floor-or-retained-key lower bound. The owner froze optimization for #3504 and requested filing residual measured findings after one closing review. Related broader costs: #4286. No release commitment or customer impact established.

Deferred from #3504.

Review-Deferral: 7906dae330f9e56e severity=major category=performance

_{🤖 Generated by OpenAI Codex; posted via @kriszyp.}