Benchmark the dense-array book against BTreeMap and fix complexity claims

[weiminglong]

Summary

ADR-0002 dismissed alternatives without measurement and repeated an incorrect "O(1) best bid/ask" claim in four places (BTreeMap first-element access is O(log n)). Worse, it never evaluated the design any order-book discussion on a bounded grid starts from: a dense array indexed by tick with a best-price cursor.

• New array_book benchmark (pb-book): implements the dense-array side at full strength — epoch-stamped cells so a snapshot rebuild is O(levels) rather than an 80 KB clear — and runs it against L2Book on identical workloads (snapshot rebuild, resting-level delta, top-of-book read, top-10 depth, best-level churn).
• Measured (Apple M3, 50 levels, 10-tick spacing): array wins writes 10–19× (59 ns vs 1.11 µs snapshot; 0.73 ns vs 7.7 ns delta; 3.8 ns vs 26 ns churn), ties top-of-book (2.6 vs 2.8 ns), loses top-10 iteration slightly (39 vs 31 ns).
• ADR-0002 rewritten with the measured table and the explicit retention rationale: book operations are not the pipeline bottleneck (~1 µs worst case against ~0.5 µs deserialize + ~0.5 µs WAL per event), the array pins ~320 KB per asset and couples the book to the venue's tick grid, and near-resolution sparse books degrade its top-k scans. The crossover condition for switching is recorded, and the benchmark keeps the comparison re-runnable.
• O(1) claims corrected in README, docs/architecture.md, and docs/latency.md to the measured ~3 ns figure.

Verification

• Benchmark compiles and runs (cargo bench -p pb-book --bench array_book); results above from a full run
• pb-book tests green, clippy (--all-targets -D warnings-clean), fmt clean, hygiene gate clean