Hot ingestion: minimum optimization to fit the Phase 2 budget #974

Goal

Phase 2 (1 s block time) gives ingestion 405 ms p99 per ledger. Hot ingestion on feature/full-history must stay under that for a whole 10,000-ledger chunk. Currently we're able to fit within that budget on small 500-1000 ledgers run, but fail when we run on the full chunk.

Problem

Full-length Phase 2 runs on the sac-5000 profile miss the budget. Runs capped at 1,000 hot ledgers pass, so the pass was an artifact of the cap.

Same commit, box type and dataset. The other five ingest phases do not change. The growth is in apply: ConcurrentBitmaps.AddTo clones each dense term's roaring bitmap on every write, and the clone cost grows with the number of containers as the chunk fills. Every published run since July shows the same dependence on hot-leg length.

Work

• Confirm the cause: per-phase breakdown of both runs, sweep of all 28 published runs, local reproduction on synthetic ledgers.
• Make dense terms writer-owned and publish reader snapshots lazily. stellar-rpc#973.
• Validate at full length on c6id.8xlarge: sac ingest p99 508 → 153.5 ms, apply p99 344 → 14.2 ms. phase2-lazy-snapshot-optimization-full-6cd08c13-20260903T020032Z
• Merge events: snapshot dense index terms lazily so apply latency does not grow with chunk fill #973.
• Run Phase 1 and Phase 3 at full length on the merged branch and record the results.
• Set hot_num_ledgers=0 as the default for phase verdict runs. Capped runs stay for query-only work and smoke tests.

Out of scope

Memory growth of the in-memory index over a chunk (peak RSS 10.6 GiB on sac at full length). #902 addresses it with a new index and row format.

Acceptance

Full-length Phase 2 hot ingest p99 under 405 ms on all three profiles, on the merged branch, in a published run.