state_sync cannot converge entities that changed while a peer was fully disconnected

[Mearman]

The state_sync receive path in handleDataMessage (src/core/mesh-store.ts) merges add-only: if (!this.agents.has(id)) (same shape for rooms, messages, dms). Since the dial-window broadcast fix (#25), patches are reliable while peers are connected, so this gap only bites when a peer is disconnected outright while an entity changes — a rename, status change, or room edit. The returning peer keeps its stale copy until some later patch about that entity happens to arrive, and any peer that syncs from it inherits the stale copy.

Reproducer shape: three TLS peers; C shuts down; A renames its agent and edits a room; C returns and reconnects. C still sees the old name and old room state, with no further patch coming to correct it.

Fix direction settled during the #23 investigation: per-entity monotonic versions. Every mutating store bumps the entity's version and embeds it in the entity record carried by patches and SerialisedState; state_sync and patch application take the higher version (ties keep the existing union semantics for room members and subscribedRooms, which also keeps concurrent joins race-safe). Owner-authority merging was considered and rejected: a rejoining peer can carry an old copy of a third peer's entity and would clobber it.

Also heals room-leave divergence, which the current member-union cannot (union only ever adds).

Found while verifying the persistent-identity work (#24) and the broadcast queue (#25).

[Mearman]

Fixed in #29: agents and rooms carry a monotonic revision the mutating store bumps, and every merge path (state_sync snapshots and incremental patches) is tri-state — strictly higher replaces wholesale (heals renames, edits, and the leave case union could never handle), equal unions memberships and subscriptions (concurrent joins from the same base both survive), lower is rejected (a stale holder cannot regress a current one). Message and DM histories merge by id with read-receipt union. The merge lives on a public applyStateSync seam and is unit-tested in both directions, wired into pnpm test.

Also extracted during the work: handleDataMessage now delegates to that seam rather than owning the merge inline.

[Mearman]

Recording an accepted design boundary for discoverability: the tri-state merge's equal-version union exists for concurrent-join race safety, and its accepted edge is that a simultaneous join and leave of the same agent at equal revisions converges with the joiner retained (the union keeps them; only a strictly higher revision can remove). Contrived in practice, since it requires the same agent joining via one peer and leaving via another within the same revision window; any subsequent room mutation bumps the revision and the wholesale replace resolves it. Deliberate trade-off, noted so nobody rediscovers it as a mystery.

[Mearman]

Superseded by #34: the equal-version join/leave boundary documented above is now resolved properly rather than accepted. Membership is a last-write-wins element set (per-agent join/leave revisions, highest wins, exact tie resolves to out), so a kick racing a concurrent join converges deterministically with the kick honoured on every peer — pinned by a test that exchanges both sync directions — while concurrent joins of different agents remain independent and both survive. The version-tie union the boundary note described no longer exists.