Avoid eager full snapshots discarded by attached SSE delivery #367

Consolidated into #313. Closed only as a superseded review thread, following Joel Z. Leibo’s category guidance. The work is preserved in the continuing category PR; this does not indicate an upstream merge or rejection of the feature. Continuing issue: #313; continuing PR: #314. Reusable server-error handling continues in PR #314; Bellwether demonstrations continue in PR #372.

Observed duplication in the attached operation stream

OperationService currently materializes a full audience snapshot on every publication, retaining up to sixteen per subscriber. SimulationServer intentionally ignores each queued snapshot and obtains a fresh one at delivery, so a queued private projection cannot survive role revocation. The queued full snapshots are therefore redundant for this listener.

In a controlled 40-update probe with a 672000-character view, the existing service built the view 66 times before delivery and retained 16 snapshots (10,755,808 aggregate serialized JSON bytes). These are code-path and serialized-payload measurements, not process RSS, transferred network bytes or a wall-clock benchmark. The real developer view measured in #362 can similarly be large.

Small compatible improvement

Add an opt-in coalesced notification subscription to the existing operation service, and use it in the existing SSE handler. Retain at most one payload-free wakeup for a current-state reader. Keep ordinary direct snapshot subscribers unchanged, and keep snapshot construction/authorization at delivery. Domain events, revisions, retry semantics, JSON envelopes, heartbeat comments and reconnect state stay intact.

Acceptance

Verify default subscription ownership/behavior; initial scope rejection; zero view construction during notification-only publication; latest revision and complete event ledger under a burst and concurrent updates; unsubscribe; and actual HTTP delivery after a principal loses its private role. Exercise existing large-editor and multiplayer/reconnect browser journeys and the legacy server tests.

The focused contribution depends on #366 and the existing attached-operation stack. It does not replace the server/protocol or compress delivered full snapshots, and it does not change hosted games or claim a physical-device latency improvement.