Rollup writes now lock per row, through 64 lock stripes per partition

[koculu]

Summary

Rollup writes now lock per row, through 64 lock stripes per partition, instead of once per tree. Ingestion is about 2.6× faster without rollup indexes and 3.1× faster with them. The full suite passes, 870 of 870.

Changes

• RollupWriter hashes each key to one of 64 stripes, each with its own lock and its own pending replacement. Workers update different rows of a partition in parallel; the same row is still updated one writer at a time.
• The retry guarantee holds: a failed upsert's replacement is finished before any later write of that row.
• The index copy still runs under the row's lock, so a row's copies are written in order.
• I didn't use TryAtomicAddOrUpdate.

Validation

• WritesOfRowsInOtherLockStripesDoNotWait: a copy hook holds one row's lock while a row in another stripe is written. It failed on the per-tree lock, where the second write waited.
• ConcurrentWritersOfTheSameRowsAddEveryDelta: 16 writers make 16,000 updates over 50 overlapping rows, and every delta must be counted exactly.
• The existing retry and failure tests pass unchanged.

Measured (playground, 1M events over 365 days, 20 workers, two alternating rounds; one stripe reproduces the old lock):

	One stripe (old)	64 stripes
Joint rollups, no indexes	16.7–17.2k/s	44.3–46.0k/s
With the 12 dashboard rollup indexes	10.2k/s	31.6–32.8k/s
CPU per event (no indexes / indexes)	429 / 741 µs	372 / 519 µs
Allocated per event (no indexes / indexes)	132 / 325 KB	68 / 110 KB

Compaction after ingestion takes 1–3 s longer, because more data arrives sooner. Rollup indexes now cost about 29% of throughput instead of 40%.