sync: report live events when rooms enter the sliding window

[basnijholt]

What does this PR do?

I ran into this through MindRoom: agents would answer normally in active rooms, but could go completely silent in an idle room after it fell outside the current Sliding Sync list window. When a new message brought the room back into the window, Tuwunel returned it with initial: true but without num_live. The client therefore treated the entire returned timeline as history, including the message that had just arrived.

The regression and its client-visible effect are captured in mindroom-ai/mindroom#1785.

The issue is that Tuwunel currently uses roomsince == 0 both to mark a room response as initial and, indirectly, to skip num_live. Those are not opposites in MSC4186: on an incremental connection, a room can enter the list window for the first time and contain both historical context and a live suffix.

This changes the calculation to use the previous connection-wide sync position and the positions of the timeline events actually returned to the client. Event positions stay attached through ignored-user filtering and response construction, then num_live is the consecutive suffix whose positions are newer than the previous connection position.

A few details matter here:

• The first request still treats every returned timeline event as historical and omits num_live.
• A room entering because the client expanded its list range gets num_live: 0 if nothing changed.
• Limited timelines count only live events actually present in the returned slice.
• Invite responses continue to omit num_live.
• The original client pos is snapshotted before long-polling, so an empty wake-up cannot move the comparison boundary.

This is the server-side MSC4186 behavior; there is no MindRoom-specific or client-side heuristic in the change.

Regression tests cover the first response, a newly visible room with one live event, range expansion of an unchanged room, mixed historical/live timelines, and a truncated live timeline.

Verified on top of current main:

• cargo +nightly fmt --all -- --check
• cargo test --locked -p tuwunel_api client::sync::v5 — 11 passed
• cargo clippy --locked --workspace --all-targets --all-features -- -D warnings
• cargo test --locked --workspace --all-targets --all-features — 329 passed, 2 ignored; 6 state-resolution tests and the state-resolution benches also pass

Complement was not run locally. The change corrects Sliding Sync response semantics and should not affect non-Sliding Sync endpoints.

Checklist

• Code is formatted with nightly cargo fmt and satisfies clippy and rustc lints; any allowed lint is justified by an obvious reason or a comment.
• Complement compliance changes (new passes or new failures), if any, are noted in the description above.
• No config option changes are required.
• No user-facing documentation changes are required.
• I agree that my changes may be licensed under the Apache-2.0 licence and my conduct is in line with the Contributor's Covenant and Tuwunel's Code of Conduct.

[jevolk]

Your fix landed on main rebased as 704b6c4 with your authorship intact, but a history rewrite on our side meant your branch head itself was never merged, so GitHub shows this stranded open. We would re-point the branch ourselves, but organization-owned forks do not accept maintainer pushes.

If you force-push the landed commit onto this branch, GitHub should be able to record the pull request as merged:

git fetch https://github.com/matrix-construct/tuwunel.git main
git push --force origin 704b6c4807f812fd441238a16b053ec1c3e90cee:refs/heads/fix/upstream-msc4186-num-live

Thanks for the fix, and sorry for the dance.