Fix state events missing from MSC4222 state_after when the since token falls inside a persist batch

[barodeur]

This PR fixes the issue described as comment here: #18793 (comment)

In Element Call, this shows up as ghost participants: someone who left the call keeps being displayed until a later state change refreshes the room.

The bug is not specific to Element Call: any state event can be affected, RTC membership just changes often enough to make it visible.

What happens

Alice has a client syncing against a homeserver where events are persisted by one worker (the event persister) and /sync is served by another (the sync worker). Her client is parked in a long-poll: GET /sync?since=s99&timeout=30000.

Bob joins a call at the same moment Carol sends a message. Carol's message reaches the persister first; Bob's m.call.member arrives while that write is still in flight, so the per-room persist queue groups them into one transaction:

events (each gets its own stream ordering):
    stream_ordering 100:  m.room.message   Carol
    stream_ordering 101:  m.call.member    Bob        (state)

current_state_delta_stream (how state_after finds state changes):
    stream_id 100 ────►  (m.call.member, @bob) -> $bob_join_call
          ▲
          └─ stamped with the batch MINIMUM (100), not the event's own 101
              (see `_update_current_state_txn`)

The transaction commits: both events and the delta row are now in the database, atomically.

The persister then announces the new events over replication, one RDATA token per stream ordering — rows are only merged into one token when they share a position, and 100 and 101 don't. So the sync worker's events-stream position steps 99 → 100 → 101, and on reaching 100 it pokes the notifier.

Alice's long-poll wakes at exactly that moment. Her response is built at the worker's current position — end = 100 — with RDATA 101 still in the queue:

Sync A  (since=99, end=100):
  timeline:     events   99 < ordering ≤ 100  →  [Carol's message]
  state_after:  deltas   99 < stream_id ≤ 100 →  [$bob_join_call]  ← delivered EARLY
  next_batch:   s100                                               ← mid-batch token

No race on the client's side is needed: the server hands out the mid-batch token as next_batch. Alice's client re-polls with it, as every sync client does. The worker has meanwhile processed RDATA 101:

Sync B  (since=100, end=101):
  timeline:     events   100 < ordering ≤ 101  →  [Bob's m.call.member @101]  ✓
  state_after:  deltas   100 < stream_id ≤ 101 →  []     row is stamped 100   ✗

A state event in the timeline with an empty state_after. An MSC4222 client trusts state_after over timeline state events, so Alice's copy of Bob's call membership never updates from this response.

On a single process this cannot happen: the batch's stream IDs are released as a whole, so the position visible to /sync jumps 99 → 101 and s100 is never handed out. Only a process that learns its position from replication — any sync worker — ticks through the middle of a batch.

Pull Request Checklist

• Pull request is based on the develop branch
• Pull request includes a changelog file. The entry should:
  • Be a short description of your change which makes sense to users. "Fixed a bug that prevented receiving messages from other servers." instead of "Moved X method from EventStore to EventWorkerStore.".
  • Use markdown where necessary, mostly for code blocks.
  • End with either a period (.) or an exclamation mark (!).
  • Start with a capital letter.
  • Feel free to credit yourself, by adding a sentence "Contributed by @github_username." or "Contributed by [Your Name]." to the end of the entry.
• Code style is correct (run the linters)