fix: order session lists so states stop flapping and notifications repeat

[deymosh]

Problem

On the phone a session sometimes:

• showed as stale when it wasn't;
• flapped thinking → done → thinking → done with no work;
• re-sent the same "finished" notification.

Cause (traced): the phone applied every session-list heartbeat as it arrived, with nothing to say which list was newest. The same list reaches the phone over every relay and over the direct link, the bridge can re-publish one, and after an app restart the direct link replays the last couple of minutes of the bridge's events. Any of these can apply an older list over a newer one, which:

• steps a finished turn back to running;
• marks a newer session stale;
• re-fires "finished" when the newer list re-applies. The machine store is persisted, so this also happened across a restart.

Fix

• protocol: sessions gets an optional rev, with a corpus fixture (valid and rejected).
• bridge-core: every list carries a strictly increasing rev: the clock in ms, kept ahead of the stored last value, so a restart or a clock set back can't lower it. A list is also published only when a turn state actually changes.
• client-core / client-runtime: each machine remembers the newest applied rev, persisted with the machine store. An older or equal list is ignored entirely: no state change, presence update or notification. A session-failed is announced only once.
• docs: PROTOCOL.md describes the ordering.

Test plan

• cargo clippy --workspace --all-targets -D warnings, cargo test --workspace
• bridge e2e (-p bridge-runtime --test e2e -- --ignored)
• New tests:
  • revs increase within a run and across a restart with the clock behind;
  • a late Running list and a replayed Idle list change nothing and announce nothing;
  • the rev survives the store;
  • a newer turn is announced again;
  • one failure is announced once.

🤖 Generated with Claude Code