feat(tess): add Mos coordination boundary

docs/tess/ARCHITECTURE.md

@@ -52,6 +52,21 @@ Termination is fail-closed: a runtime approval verifier consumes a one-time, exa
 | Destructive, privileged, external/customer-visible action                   | Human approval + policy | Propose, wait for durable one-time approval, then execute idempotently |
 | Provider-specific unsupported action                                        | None                    | Fail closed; never emulate silently                                    |
 
+### Mos Coordination Boundary
+
+`@mosaicstack/coord` exposes only the transport-neutral `MosCoordinationPort`
+verbs `handoff`, `observe`, and `result`. Gateway derives the actor, tenant,
+correlation, and interaction-agent identity from authenticated context plus
+trusted configuration; callers never provide an orchestration target. It
+rejects unconfigured identities, self-delegation, target/correlation drift, and
+cross-tenant handoff reads before an adapter call. No dispatch, assignment,
+review, merge, or cancellation API exists at this boundary.
+
+M4 uses a deterministic native in-process queue adapter to prove the handoff →
+observe → result flow without coupling the contract to tmux. A fleet/tmux
+adapter is deferred to the M5 live-deployment seam and must implement the same
+port.
+
 ## Session and State Model
 
 A Tess session has stable `sessionId`, `tenantId`, `ownerId`, provider/runtime identity, ingress bindings, cursor, checkpoint, inbox/outbox, and idempotency records. Discord and CLI bind to the same authorized session. Ownership is verified server-side on every list/read/attach/send/terminate operation.