Establish the live state and find a rollout precondition for G10

G10 waits on custody and platform owners and cannot close from here. What was
doable: verify the handoffs actually went out, replace a remembered live state
with an observed one, and find out whether main is safe to deploy. The last
question found a defect in this repository's own recent work.

Handoffs verified independently rather than trusted: all seven messages are in
the hub with receipt ids. This gap was reopened once for claimed-but-unsent
delivery, so the claim deserved the same scrutiny.

Live state read from the cluster read-only: image main-153258b, only the Qonto
secret materialized so the approval clients remain unprovisioned, four registered
clients, no tenantEngine block. That also corrects an earlier claim of mine --
the deployed config sets userOU explicitly, so the KEY-WP-0023 default fix was
never a production issue.

The precondition: KEY-WP-0019 discovers the expected issuer from
authelia.tokenBaseURL, and the deployed Authelia derives its advertised issuer
from the request Host, advertising the in-cluster address to KeyCape and the
browser-facing one to browsers. Verification fails closed, so a mismatch breaks
every human login and looks like a broken login rather than a misconfiguration.
Which value the token carries needs a real login against production to settle and
was not determined here.

Two mitigations: docs/operations.md documents pinning authelia.issuer and
jwksUrl, with the curl that reveals what the provider advertises for a given
Host; and the authentication failure event now carries a specific reason, so
id_token_issuer_mismatch is distinguishable from a signature failure or an
unreachable key set. The browser still learns nothing.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NV9oijZukGyGbRQGGKnK4P

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 713576@bnt-lap001
Assistant-Session: 384c511d-9bce-4cb8-a676-2aef6c0c8df6

history/2026-09-05-011726-scope-intent-assessment.md

@@ -464,6 +464,31 @@ register the real callback, deploy and verify the new contracts, reconcile token
 types at consumer boundaries, and retain handoff receipts. Repo-local source
 changes cannot alone establish these outcomes.
 
+**Status 2026-09-08 (KEY-WP-0027): still open, and correctly so.** The handoff
+hygiene half is discharged: all seven messages are present in the hub with
+receipt ids, verified independently rather than taken on trust, since this gap
+was reopened once for exactly that reason. No replies yet.
+
+Live state observed read-only rather than remembered: image `main-153258b`,
+only the Qonto secret materialized (so the two approval clients remain
+unprovisioned), four registered clients, no `tenantEngine` block. An earlier
+claim of mine is corrected there: the deployed config sets `userOU: "ou=people"`
+explicitly, so the KEY-WP-0023 default fix was never a production issue.
+
+**Rollout precondition found in this repository's own work.** Upstream
+verification (KEY-WP-0019) discovers the expected issuer from
+`authelia.tokenBaseURL`, and the deployed Authelia derives its advertised issuer
+from the request Host — in-cluster it advertises
+`http://authelia.sso.svc.cluster.local:9091`, browser-facing
+`http://auth.coulomb.social`. Verification fails closed, so a mismatch breaks
+every human login and presents as a broken login rather than a misconfiguration.
+Which value the token carries was not settled, because doing so needs a real
+login against production. `docs/operations.md` documents pinning
+`authelia.issuer`/`jwksUrl`, and the failure now reports a specific
+`id_token_issuer_mismatch` reason so it is diagnosable in seconds.
+
+The rest is owner work and stays open.
+
 ## Deliberate exclusions are not defects
 
 INTENT excludes general-purpose IAM, weakened flows and expanded-mode operations.