[kyscott18]

Supersedes #61.

Summary

Accepted batches, force-included mutations, and inclusion updates were committed inline, mostly under the speculative-state lock, so execution, submit, and watch waited on Postgres. One persist fiber now does every runtime database write.

• Group commit. The fiber takes everything that queued during the previous commit and writes it in one transaction. The batch loop never waits on Postgres, so batch N+1 executes while batch N commits.
• Ordering. Inserts are queued under the lock right after executing, so they commit in execution order. Restart resumes after the highest committed execution index without checking for gaps, so a later insert must not land before an earlier one.
• execute fails fast on a rejection. An accepted mutation's caller then waits, outside any lock, for its own batch's commit.
• submit executes force-included mutations and queues their insert under the lock, then simulates. After the lock it waits for the commits of exactly the batches and force-included mutations it settles, then broadcasts. Nothing settles onchain before it is committed.
• The inclusion update is not awaited. Nothing reads it, and the rows it updates are already committed.
• Failure. A failed commit fails the persist fiber, which stops the program, and waiting callers get TypewriterStoppedError.

🤖 Generated with Claude Code