[Bug] Recovery seeds sequenceNr only from snapshot/events — a fully compacted journal permanently blocks persist

[pathosDev]

Problem

Replay.replayState seeds sequenceNr = 0 and only advances it from a replayed snapshot or replayed events — it never consults journal.highestSeq (src/persistence/Replay.ts:72, 93-99). PersistentActor adopts that value as _seq (src/persistence/PersistentActor.ts:231-232) and persistAll passes it as expectedSeq.

After a compaction that removed every event with no surviving snapshot, every backend correctly preserves its high-water mark (RelationalJournal.readHead, InMemoryJournal.highWater, Cassandra max_sequence_nr, DynamoDB deletedTo) — so the very next persist() throws JournalConcurrencyError(expected 0, actual N). Permanently. The actor can never write again.

This is the direct consequence of the fix for #379 (the high-water mark deliberately never rewinds); the replay seed was not updated to match. The journal contract suite has "full delete preserves highestSeq" (tests/integration/brokers/lib/persistence-contract/journal.ts:204), but nothing exercises the actor-level recovery path.

Proposed behaviour

Seed sequenceNr from max(snapshot.sequenceNr, await journal.highestSeq(persistenceId)) in replayState. assertTrustworthySnapshot already reads highestSeq, so the snapshot path pays no extra round-trip.

Acceptance criteria

• Append 10 events, journal.delete(pid, 10), restart the actor → persisting event 11 succeeds.
• Covered at the actor level (not only the journal contract), across the contract harnesses.

Related: #379 (closed — created this condition), companion issue on the deleteHistory footgun that triggers it: #629

[pathosDev]

Course notes: the fix cannot live where it looks like it should, and #629 has to land first.

1. Not in replayState. The natural home for "seed the sequence from the journal's high-water mark" is replayState, where the sequence is computed. That would be wrong: replayState is shared with DevTools time travel (src/devtools/replay/TimeTravelMethods.ts), which passes toSequenceNr and needs the sequence to stay at the requested point in history. Seeding it from the journal's head there would silently break the time-travel panel.

The fallback therefore sits in PersistentActor.recover(), which is the only caller that means "recover to now".

2. Guarded on sequenceNr === 0, not applied unconditionally. An unconditional max(replayed, highestSeq()) costs an extra query on every actor start — meaningful for a sharded system activating many entities. Guarding it means the query runs only when there was nothing to replay at all, which is exactly the compacted case. A brand-new actor takes the same branch and highestSeq returns 0, so the clamp cannot invent history; there is a test for that.

3. Ordering with #629. Both fixes are in PersistentActor.ts and the round-trip test needs both, so the commits had to be split with #629 first — otherwise whichever lands first leaves the suite red and the tree un-bisectable. Details in #629.

4. Why this got worse rather than better over time, since the report does not spell it out and it affects how you read the severity: before #379 the journal also reported 0 after a full compaction, so recovery and the journal agreed and sequence numbers were quietly reused. #379 gave every backend a durable mark of what it had deleted — correctly — and in doing so turned a silent inconsistency into a permanent, unrecoverable failure. The right conclusion is not that #379 was wrong, but that this was always broken and only became visible when the other half started telling the truth.