Events keep their order across processes: replays resume by the table's own sequence #932

Never down (#873). Found in #924's review.

Event ids are ULIDs. One process makes them in order: a second id in the same millisecond steps its random part forward. During a roll, though, two processes write to one database (#875), and each one's ids are in order only among its own. An event written by one process in the same millisecond as the other's can get the smaller id. Ids made in SQL (a migration's) have no such step at all.

Every replay resumes "after the last id seen": the live stream's since and Last-Event-ID, and the lists newest first. So a browser that reconnects can skip an event that was written, but sorts below where it stopped.

Acceptance criteria

• [ ] Events are ordered, and every replay resumes, by the event table's own sequence (its rowid), which SQLite keeps strictly increasing across every connection. The id stays the event's public name, and a cursor stays an id.
• [ ] The repository stream resumes from Last-Event-ID / since like the forge-wide one.
• [ ] A test: two connections write in the same millisecond, the second with the smaller id, and a stream resumed after the first misses nothing.

Follow-up from #936's review: the event table's rowid can be renumbered by VACUUM, so replays now read an explicit seq (migration 69), set by a trigger on every insert. Pull: steward/event-seq.