Authoritative server

AuthoritativeServer owns an Engine and Chronicle on the server. Clients use the JSON command protocol (welcome, state, describe, dispatch, history, dispatch:result, and error) rather than directly exchanging CRDT sync messages with one another. RoomAuthoritativeServer creates one Engine per room, validates membership, and serializes dispatches through a per-room queue.

The server's outbound projection boundary allows subclasses to define what a principal receives. Unknown outbound categories are dropped, error strings and room codes are sanitized, and history is denied by default because actions can contain private payloads. These are trust-boundary mechanisms, not a general claim that the product prevents cheating; game-specific validation still needs to be implemented and reviewed.

Use this model when a central Engine should be the state owner and clients should receive server-projected state. It is a different topology from the relay-assisted CRDT mesh, not an alternate relay configuration.