fix(control): enforce a consistent public-state size budget before publication #208

What happened

Stability audit finding F09 / P2 (2026-09-27). Priority is an audit recommendation, not a claim of a production incident.

Control and Python Relay readers reject public-state files above 1 MiB, but Control publishes the full device map without enforcing the same budget.

A synthetic 5,001-device fixture published a 1,142,105-byte snapshot successfully and the existing Control instance remained healthy. Constructing a new Control instance failed with unsafe_public_state; Relay has the same reader cap. These device counts are fixture-specific, not a claimed supported capacity or a statement about current production size. Per-user device limits do not bound the whole map, which also retains revoked rows.

What you expected

Align publisher and reader capacity contracts. Reject or safely handle growth before replacing a readable committed snapshot, preserve valid state/readiness, and define an actionable capacity error. Do not silently discard revocation records.

Environment

• Baseline: published session-peer v1.0.1, commit 55168c3bea5a49e81916fdead57d3634def6b1d6.
• Reproduction: isolated source/tag fixtures; no live message/ACK tests or production mutation.
• Audit environments: macOS arm64, Python 3.14.7; Control tests use Node 22.14.0. Linux evidence is explicitly identified above where applicable.
• Discovery output: not applicable to this fixture; no real session identifiers or credentials are included.

Source evidence

• control/src/server/relay-control.ts#L141
• control/src/server/relay-control.ts#L164
• session_peer_relay/auth.py#L123

Acceptance criteria

• Test serialized byte sizes just below, at, and above the common limit with variable-length fields and revoked devices.
• After a rejected over-capacity mutation, both current readers and a restarted Control/Relay remain usable and state-consistent.
• Document capacity enforcement and independently deploy the Control fix where required.

Scope and limitations

This is a writer/reader contract mismatch, not evidence of a production capacity incident.

Target: v1.0.2 stability work. This issue does not authorize a release or operating-service changes. Offline reproduction establishes the failure mechanism, not attribution of historical #161 incidents.

Checked

• Searched existing issues for duplicates.
• Removed credentials, conversation contents, private paths and real device/session identifiers.
• Used isolated fixtures without weakening inbound permissions.