Make signed N-1 relay compatibility a release gate

[callumalpass]

Problem

Beta.91 made policy-freshness-lease-v1 a required relay capability. The immediately previous production beta.90 connector does not advertise it, so the beta.91 server rejects the relay handshake with capability_contract_incompatible and close code 4406.

The signed previous-client staging matrix passed because its scenario exercised only a local_only collection. It did not authenticate and complete a real previous-client relay handshake against the candidate server. The beta.91 production release was rolled back to beta.90 after this was discovered.

The rejection also reports the stale generic minimum_connector_version beta.33, which is not the first release implementing the current required capability set.

Required contract

The immediately previous production client (N-1) must remain compatible through a normal release unless an explicitly reviewed breaking-release exception is recorded before staging.

Acceptance criteria

• Candidate qualification runs the exact signed N and N-1 clients through authenticated relay handshakes and representative remote read/write/revocation operations against the candidate server.
• Evidence fails if either client remains local_only, never establishes relay authority, or cannot prove cleanup.
• New relay capabilities use an advertise/optional/adoption/required rollout, or an explicit breaking-release record explains why compatibility cannot safely be preserved.
• The server's upgrade hint is derived from the capability contract or otherwise cannot claim a stale minimum version.
• Deterministic regressions cover N-1 compatibility and intentional breaking exceptions.
• The release runbook and deployment report contract identify N-1 remote compatibility as a production gate.