Recover paired history insertions before exposing stored objects

[a-shannon]

Uses shared test support from #2535. Review the history increment; the upstream diff is cumulative until the prerequisite merges.

A paired history insertion can persist an object before its indexes fail. The object's presence then prevents ordinary processing from completing those indexes. Record a durable intent, write the objects, and atomically publish indexes with intent removal. Publish caches afterward. Ordinary persistence failure makes the live instance unavailable; reopening validates and replays its recorded insertion before exposing reads.

The change adds an explicit synchronous batch API, retains existing object/index encodings, and reserves a private non-hash index key for recovery. Acquisition and initialization failures close acquired stores while preserving the original error.

The initial storage increment passed 33 tests across recovery, durable batches, journal decoding, factory cleanup and existing consumers. They cover before/after acknowledged-write outcomes, retried recovery, object identity, exact malformed-record rejection, cache publication and control-exception propagation. Independent source and evidence reviews completed.

Decoded-object caching exposed an existing header-size calculation error: a history type prefix was counted as part of the header. HeaderSerializer now measures consumption relative to its own entry. Header bytes and IDs are unchanged. The follow-up passes 18 serialization tests and all 10 blocks API route tests, preserving full JSON equality. All eight checks, including integration, passed at 223ea95c6 (CI run). The earlier integration timeout is historical evidence, not a result attributed to this head.

This covers recorded paired insertions, not repair of existing unjournaled orphan objects or all history mutation APIs. No OS power-loss guarantee is inferred. #2523 retains ownership of removal-error propagation. When composing with #2424, its additional index/raw-removal methods must also respect the availability boundary.