Register the approver client now its callback exists

informed-decision submitted client_id informed-decision-approver and redirect
https://decisions.coulomb.social/auth/callback, with the origin already live and
verified by them rather than reported: both / and /auth/callback return 200 on a
Let's Encrypt certificate valid to 2026-12-09. The host is decisions, not the
decide of an earlier draft. Its path serves a placeholder for now, which does not
matter -- the redirect is matched as an exact string and never fetched.

Published as a public authorization_code client with S256 PKCE, audience
approval-engine, scopes openid/approval:read/approval:approve, mfaRequired true
and a declared tenant:platform. No secretRef, since PKCE is the whole proof.

TestApproverRegistrationShapeIsExact pins every field, so widening a scope or
relaxing MFA fails the build rather than reading as an edit, and asserts the
registration passes startup validation -- proving the KEY-WP-0028 tenant
exemption holds for the registration that actually depends on it.

Two existing guards fired on the way in and neither was loosened. The tenant pin
refused an unreviewed client carrying a tenant, which is its purpose, so the
approver was added to its reviewed set deliberately. And the audience test
panicked slicing secretRef[4:], an assumption that held while the fixture had
only confidential clients; the approver is the first public one, so the loop now
guards on the env: prefix.

The declared tenant reaches the token by the GH-DEC-2026-013 gap route by
construction, and tenant_source says so: registration, never directory.

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

workplans/KEY-WP-0013-approval-engine-resource-audience.md

@@ -348,10 +348,9 @@ indefinitely.**
 
 ```task
 id: KEY-WP-0013-T05
-status: wait
+status: done
 priority: high
 assignee: the-custodian
-blocking_reason: "Client ID and deployed callback pending INFD-WP-0001-T07 from informed-decision. The tenant blocker is resolved in code."
 state_hub_task_id: "9a782909-91db-59fa-aae7-83766f4fbb0d"
 ```
 
@@ -435,10 +434,49 @@ the relabel refusal. Verified with teeth — neutering the conflict check makes
 `docs/approval-engine-auth-contract.md` states the requirement on the approver
 client, and the provisioning packet now declares `tenant: tenant:platform`.
 
-Task stays `wait` on one thing only: `client_id` and callback URI from
-INFD-WP-0001-T07, once informed-decision has a deployed origin. The owners were
-asked which resolution they prefer and have not answered; that answer is no
-longer blocking, and this implementation is compatible with either.
+**Cleared and registered 2026-09-10.** informed-decision submitted the two
+strings with the origin already live:
+
+    client_id     informed-decision-approver
+    redirect_uri  https://decisions.coulomb.social/auth/callback
+
+The host is `decisions.coulomb.social`, not the `decide.coulomb.social` of an
+earlier draft. They verified the origin rather than reporting it: `/` and
+`/auth/callback` both return 200 from 92.205.62.239 on a Let's Encrypt
+certificate CN=decisions.coulomb.social valid 2026-09-10 to 2026-12-09. The path
+serves a placeholder while their surface is gated on APPROVAL-WP-0002-T01, which
+does not affect the registration — the redirect is matched as an exact string at
+`/authorize` and never fetched.
+
+Published in `config/service-clients.example.yaml`: public `authorization_code`
+with S256 PKCE, `audience: approval-engine`, scopes
+`[openid, approval:read, approval:approve]`, `mfaRequired: true`, declared
+`tenant: tenant:platform`. No `secretRef` — PKCE is the whole proof — and no
+`serviceSubject` or `roles`, which validation rejects on a browser client.
+
+`TestApproverRegistrationShapeIsExact` pins every field, so widening a scope or
+relaxing MFA fails the build rather than reading as an edit, and asserts the
+registration passes startup validation — which proves the KEY-WP-0028 tenant
+exemption holds for the registration that depends on it, not only in a synthetic
+case.
+
+Two existing guards fired on the way in, both correctly, and neither was loosened:
+
+- `TestServiceRegistrationTenantsAreExactPerDecision` refused an unreviewed client
+  carrying a tenant, which is exactly its purpose. The approver was added to its
+  reviewed set as a deliberate act.
+- `TestServiceRegistrationAudienceAndScopeIsolation` panicked on
+  `secretRef[4:]`, an assumption that was safe while the fixture held only
+  confidential clients. The approver is the first public one; the loop now guards
+  on the `env:` prefix.
+
+The tenant is declared, and the token says so: `tenant_source` is `registration`,
+never `directory`. Per gate-house's correction that is adequate for
+approval-engine's store-isolation gate and **never** for doctrine turning on this
+person's membership of the zone.
+
+Not live: this is a published registration fragment. Deployment is owner-side and
+nothing has been issued to a real approver.
 
 ## Make negative rollout evidence discriminate actual issuer refusal