raw-events: keep last_received_event_seq consistent under insert races

[kunickiaj]

Problem

MemoryStore.record_raw_events_batch() allocates an event_seq range up-front and then inserts rows. Under concurrent inserts / races, some inserts can still hit IntegrityError, which can leave:

• gaps in event_seq, and
• raw_event_sessions.last_received_event_seq ahead of the highest actually inserted event.

Flush currently uses MAX(event_seq) from raw_events, so this may not break flushing, but it makes session state misleading.

Expected

• last_received_event_seq should reflect the highest successfully inserted event_seq.

Actual

• Under races, last_received_event_seq can get ahead.

Proposed fix

• After the insert loop, reconcile last_received_event_seq to MAX(raw_events.event_seq) for that session (or redesign allocation so the counter only advances for successful inserts).
• Add a regression test that simulates duplicates/races (as much as feasible in unit tests).

Acceptance criteria

• last_received_event_seq matches the max inserted seq after batch insert.
• Test added.

[kunickiaj]

Current triage: still relevant.

In the current TS store path (packages/core/src/store.ts), batch raw-event insert still allocates a last_received_event_seq range up front and then inserts with onConflictDoNothing(). I did not find a reconcile step afterward to pull last_received_event_seq back to the highest actually inserted sequence.

So the inconsistency described here still looks plausible under races/conflicts and should stay open.