core/mvcc: experimental_group_commit_delay_us

[pereman2]

• Implement group commit for MVCC: multiple concurrent transactions batch their fsync calls into a single fsync, trading commit latency for throughput
• Add PRAGMA experimental_group_commit_delay_us to configure the batch window (0 = disabled, default)
• Add --group-commit-delay flag to the write-throughput benchmark

Currently each MVCC commit holds the pager_commit_lock for the entire duration of: log write → fsync → offset advance. The fsync dominates (~milliseconds on SSD), serializing all concurrent commits.

Group commit splits this: transactions write their log record and advance the offset under the lock (microseconds), then release the lock and join a SyncGroup to wait for a batched fsync. The first transaction to observe the batch window expired becomes the leader via CAS on leader_claimed, seals the group, and issues a single fsync covering all pending writes. Followers poll sync_done and proceed once set.

New state machine flow (group commit enabled):

BeginCommitLogicalLog  →  WaitForGroupSync [NEW]  →  EndCommitLogicalLog  →  CommitEnd
   (write + advance         (join group, leader       (schema updates,        (mark Committed,
    offset, release lock)    election, batched fsync)   header copy)            notify deps)

[turso-bot]

Please review @sivukhin

[codspeed-hq]

Merging this PR will degrade performance by 15.72%

❌ 2 regressed benchmarks
✅ 277 untouched benchmarks
⏩ 105 skipped benchmarks¹

⚠️ Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
❌	Simulation	concat_blobs	1.4 µs	1.7 µs	-15.72%
❌	Simulation	ltrim_with_pattern	1.2 µs	1.4 µs	-15.04%

---

_{Comparing pereman2:mvcc-group (9cc2018) with main (e6d0612)}

Footnotes

1. 105 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩