Record the operator withdrawal and the gate-house tenant conditions

approval-engine answered the presenting-actor question we put to them and the
answer withdrew the client: nobody presents approval-engine-operator. Nothing in
their repository obtains an OAuth token, and scope by scope the bundle never
described a single actor -- approve belongs to the human client, emit is
redundant, and no requester identity was ever settled for create. Annotated as
withdrawn in the example config and the packet rather than deleted, because they
asked for it to stay authenticable under CCR-2026-0018 if a presenter appears.
The separation-of-duties observation is kept because it constrains the
re-request: approve must not travel with the operational scopes.

Raised rather than filed: "do not provision" cannot undo a provision. The client
went live in the 2026-09-09 attended rollout, so the estate now holds a
confidential credential that can create and approve approvals, that nobody
presents, and that no consumer awaits. Standing capability with no counterparty
is a worse resting state than either provisioning it for a named presenter or
disabling it. Disablement is KeyCape's to execute and not KeyCape's to decide
alone, so it goes to the owners rather than into a commit.

Also records GH-DEC-2026-013 conditions (a) and (b) in the tenant contract, both
of which strengthen what we had written about ourselves. Row four is normative,
and in the direction we would not have guessed: a future change preferring the
DIRECTORY is also void, because "the directory won" is still a winner and picking
any winner turns a refusal into a silent cross-tenant assertion. And lifting the
dynamic-registration exclusion now VOIDS the registration-bound shape that day
rather than reopening it for review -- our "must be revisited" was too weak.
The shape is recorded as a declared bounded gap, not the terminal state.

Verification note: the Go suite could not be run green for this commit because a
peer session is mid-edit on token.go and human_tenant_test.go for the §5
provenance work. Every file in this commit is YAML or Markdown; both YAML files
were parsed and the example config's scope set and tenant were asserted unchanged.

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

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1182213@bnt-lap001
Assistant-Session: 966597b9-ae61-46a4-8b9e-1594ab3ec4ad

docs/approval-engine-provisioning-request.yaml

@@ -92,6 +92,15 @@ verification:
 # gate-house's.
 presenting_actor_note:
   client_id: approval-engine-operator
+  # ANSWERED 2026-09-09 by approval-engine: the presenter is nobody, and they have
+  # withdrawn the request. Nothing in their repository obtains an OAuth token; the
+  # engine only verifies them. They asked railiance-platform to cancel the
+  # client-side reader CCR-2026-0020 as an owner decision. Verifier custody
+  # CCR-2026-0018 stands. The separation-of-duties observation below is what
+  # prompted the question and is retained because it constrains the re-request:
+  # approval:approve must not travel with the operational scopes.
+  status: withdrawn-by-requesting-owner
+  already_live: true   # provisioned in the 2026-09-09 attended rollout; withdrawal does not unprovision it
   observation: |
     The registration as issued carries both approval:create and approval:approve,
     so a single presenter can create an entry and then approve it. That is a