Events: an explicit seq for replays, which VACUUM cannot renumber #948

Follow-up to #932 (#936), from its review. Migration 69, appended last.

#936 ordered events and resumed replays by the table's rowid. The event table has no INTEGER PRIMARY KEY, so VACUUM (and a VACUUM INTO snapshot) may renumber those rowids. Now each event carries its own place:

• Migration 69 adds event.seq, backfills it from the rowid, and indexes it: unique on seq, and on (repo_id, seq) for a repository's list.
• A trigger sets seq to the next number on every insert that does not give one: the app's bus.append, another connection, and a migration's SQL alike. There is one writer at a time, so it is strictly increasing across every connection.
• afterEvent and both lists' ORDER BY read seq. Cursors are still the event's id, resolved on the server, as in #936.

Tests: test/event-order.test.ts. Three new cases fail without the change:

• a raw insert from another connection takes the next seq;
• a later event that lands in a reused, smaller rowid still lists and resumes after the ones before it;
• VACUUM leaves every event's seq as it was.

The five cases from #936 still hold.

🤖 Generated with Claude Code