fix(storage): refresh node group scan state after a checkpoint

[kory-io]

Description

Bug. Read-only transactions are not blocked by a checkpoint, so a checkpoint can run between two vectors of the same node table scan (or between two lookups sharing a scan state). NodeGroup::checkpoint merges all chunked groups into a single persistent one and rewrites its column chunk metadata, but the running scan's NodeGroupScanState still holds the chunked group index and the per-segment metadata (page ranges, compression metadata, dictionary sizes) captured by initializeScanStateForChunkedGroup before the checkpoint. NodeGroup::scan then reads the checkpointed pages with stale metadata, or indexes past the end of the chunked group list.

Symptoms: scans return corrupted values with no error (strings assembled from the wrong dictionary offsets, wrong integers), and a scan that was inside a committed in-memory chunked group crashes. Reproduces on main (v0.21.2) with 3 scanning connections, a delete/re-insert writer and a CHECKPOINT loop at 8 threads: garbled strings in 3 of 8 two-minute runs.

Fix. Count the checkpoints of a node group (NodeGroup::numCheckpoints, protected by the chunked-groups lock) and record the count in the scan state when it is initialized. scan, scanInternal, lookup and lookupMultiple, which already hold that lock, re-initialize the state against the checkpointed group when the counts differ. Row indices within a node group are stable across a checkpoint, so nextRowToScan is kept. Cost: one integer comparison per scanned vector / lookup.

Tests. ScanAcrossCheckpointTest.CheckpointWhileScanningPersistentGroup and .CheckpointWhileScanningInMemoryGroup drive a NodeTableScanState in a read-only transaction and checkpoint between two vectors. Without the fix the first returns wrong values and the second segfaults; with it both pass. The stress loop above: 0 of 13 runs garbled with the fix.

Verified locally: release ctest 2854/2855 (the one failure, dictionary_bug~orb383_relationship_projection_obfuscated.AnonymousParquetDeleteReload, also fails on main); ASan + runtime checks: transaction_test 87/87, storage unit tests, e2e transaction~*:dml_node~*:dml_rel~*:storage* 725/725.

Not addressed here.

• Rel-table (CSR) scans keep their own scan state across CSRNodeGroup::checkpoint and may have the same exposure.
• Separately, an open read-only transaction can see commits newer than its snapshot once they are checkpointed. That looks like a design question rather than a small fix; happy to open an issue with a short repro if useful.

Types of changes

• Bug fix

[adsharma]

Does CSRNodeGroup need the same fix?

[kory-io]

Yes. Rel scans snapshot their chunk state and CSR header once, and CSRNodeGroup::checkpoint does not bump the counter this PR checks, so that refresh never runs for them. A checkpoint also replaces the persistent group and drops the in-memory index, and CSR offsets can move, so the node-table approach does not carry over. I'll follow up with a separate test and fix.

[kory-io]

The CSR follow-up is #1116. A scan that is already running keeps the CSR state it started with. Checkpoint does not wait for it, and the node-table cursor refresh is not reused.