design: decide a server-side require_connect_token knob (token presence is not enforceable today)

[wallstop]

Summary

The #517 connect_token implementation (ratified 2026-09-11) verifies presented tokens only. When a verification key is configured, a client that simply omits connect_token is still admitted on the public app_id — that is the ratified wire contract ("absent field = today's semantics"), so released SDKs keep working.

Consequence: a configured key rejects bad tokens, never missing ones. Server-side tenant isolation is not enforceable today; hosted deployments rely on the cloud edge (option 1 of the #517 decision) to stop credential-less traffic.

What would change

Add an opt-in enforcement knob so a deployment can make token presence mandatory server-side:

• security.connect_token.required: bool (server-global), or a per-app flag on AppRegistrationEntry (per-tenant rollout, matches rate_limit_per_minute granularity).

Refusal semantics to decide

• Reuse CONNECT_TOKEN_INVALID (one code for missing + invalid; simplest for SDKs), or
• add a distinct code (e.g. CONNECT_TOKEN_REQUIRED) so clients can distinguish "fix your token" from "obtain a token first".

The refusal should stay retryable and budget-charged, like every handshake refusal.

Why an owner decision

A server-global required=true would refuse every released SDK (0.8.0–0.12.0) that never sends the field — that is exactly the compatibility contract #517 ratified. A per-app flag avoids fleet-wide breakage but adds config surface. Either way it reverses part of the ratified default, so it needs explicit sign-off before implementation.

[wallstop]

I think both solutions are good?

[wallstop]

Implemented in PR #576.

Owner sign-off recorded here for the audit trail (2026-09-12):

Question	Decision
Knob scope	Layered: server-global default + per-app override on (mirrors the layering; per-tenant rollout without fleet-wide breakage; the global default is the only knob that reaches open-policy mode)
Refusal semantics	Distinct , retryable and budget-charged like every handshake refusal ( bounds a refusal loop)

Semantics as shipped in #576:

• Effective requirement = resolved allowlist entry's , else the global default. Open-mode labels resolve no entry, so they inherit the global default.
• The posture installs with the verification key and reloads on SIGHUP on the same lifecycle; a corrupt-key reload keeps the running key and posture.
• A entry with no verification key configured is dead config: rejected at startup and by the SIGHUP gate (the running deployment keeps everything).
• The global flag cannot exist without a key (it lives inside the block), so the key-parse validation already covers it.

Red-first pins cover: layered enforcement e2e, per-app-only enforcement, open-mode enforcement, the 4006 exhaustion loop, dead-config validation, posture install/survival, projection, and the wire token golden.