Revert the npm field, re-measure coverage, and hold the layer divergence

Five inbox items worked, none of which changed a credential value or moved a
secret.

whynot-design-npm-publish: field reverted npm_token -> NPM_AUTH_TOKEN and the
path confirmed, on railiance-platform's attended, read-only, no-value field
enumeration (their docs/evidence/2026-09-10-npm-lane-field-resolution.json).
Exactly one field is present at the governed path. The 2026-09-09 change was
adopted from a coordination message and would have failed at the WP-0037-T03
rotation. The ungoverned second location is recorded as an explicit non-lane,
not deleted and not tidied away.

pep-stance coverage: published figures were stale by eight lanes (unknown
18->20, not_applicable 12->15) while resolved stayed at 3 — the denominator
moved, the classification did not. Caught by the test that asserts the published
block equals what report_coverage.py measures. tests/test_workload_join.py held
the same stale counts; both now measure the same populations.

rapp-qonto-keycape-client: blocker character updated — authority exists and is
unexercised by owner decision ("not yet", offer open), which is not the same as
no authority existing. Reopen triggers are events, never elapsed time.

flex-auth -> access-engine rename (WARDEN-IN-0003): access-engine added to the
policy-check lane's keywords so routing resolves under both names from today.
owner_repo deliberately not flipped — policy.py sends it as resource.system on
every /v1/check, and FLEX-DEC-2026-013 keeps runtime names as flex-auth.

layer declaration: INTENT.md says Staff, layer.yaml says staff, section 11 does
not say which governs. Neither changed; gate-house holds the ruling. Position in
docs/layer-declaration-precedence.md, wait in WARDEN-WP-0034-T06, and a comment
in layer.yaml telling the next session not to "fix" it — the divergence is the
evidence the ruling is made against.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 63291@bnt-lap001
Assistant-Session: 8bd77868-ca68-4f49-bb1e-d539ecc0d703

intakes/intakes.md

@@ -91,3 +91,60 @@ created: '2026-08-28T20:40:24.957468Z'
 updated: '2026-08-28T20:40:24.957468Z'
 state_hub_intake_id: "01a04d97-94cd-7b49-8019-a91c7fce8adb"
 ```
+
+## WARDEN-IN-0003 — FLEX-WP-0020 handoff: flex-auth → access-engine repository rename, credential-route surface
+
+```yaml
+id: WARDEN-IN-0003
+kind: intake
+title: 'FLEX-WP-0020 handoff: flex-auth to access-engine repository rename, credential-route
+  surface'
+status: open
+origin: cross-repo
+origin_ref: flex-auth FLEX-WP-0020 (message 0a1956c5)
+priority: medium
+owner: ops-warden
+requested_by: flex-auth
+surface: credential-route
+description: 'flex-auth is preparing the repository-coordinate rename flex-auth ->
+  access-engine. The repository UUID fda8ad85-a7d7-4055-8f21-902a533e59df and Forge
+  ID 42 are unchanged; RUNTIME names stay flex-auth per FLEX-DEC-2026-013. The ask:
+  review registry/routing/catalog.yaml''s owner repository field so routing still
+  resolves after the rename, create a live record on this side, and reply with its
+  id. No secret requested, none returned. The message is explicitly not completion
+  evidence.'
+notes: 'REVIEWED 2026-09-21; one change made, one deliberately not made.
+
+  SCOPE. Exactly one catalog lane names flex-auth as owner_repo: flex-auth-policy-check
+  (authorization decision — may this actor perform this action), warden_executes false,
+  route-only, no credential flows. Two other lanes mention flex-auth without owning
+  anything by it: flex-auth-decision-envelope-signing-key is owned by railiance-platform,
+  and ten lanes carry a policy_ref string of the form "flex-auth check secret.read:<domain>".
+
+  CHANGED. access-engine added to flex-auth-policy-check''s need_keywords, so the lane
+  resolves under both names from today rather than from the rename. That is the
+  deprecation window ops-warden asked for in WARDEN-IN-0001 and is the only change
+  routing needs: warden route find matches on keywords and lane id, neither of which is
+  a repository coordinate.
+
+  NOT CHANGED, and this is the finding worth having. owner_repo is NOT purely a
+  repository coordinate in this catalog. src/warden/policy.py sends it verbatim as
+  resource.system, and again as context.owner_repo, on every flex-auth /v1/check.
+  FLEX-DEC-2026-013 keeps runtime names as flex-auth, so flipping owner_repo at rename
+  time would rename a policy resource the PDP matches on, under cover of a repository
+  rename — a runtime change wearing a coordinate change''s clothes, and one that would
+  fail at the check rather than at the edit. It flips when the runtime name flips, not
+  when the repository does. If access-engine intends resource.system to follow the
+  repository rather than the runtime, that is a policy question for flex-auth to answer
+  before the rename lands, not an inference for ops-warden to make from its own catalog.
+
+  The lane id flex-auth-policy-check, the subsystem string, and the policy_ref strings
+  are runtime-facing for the same reason and are unchanged.
+
+  Related and unresolved: WARDEN-WP-0039-T03 already waits on the credential proxy''s
+  admitted policy binding, which is the same resource.system field seen from the
+  delegated-read side. The rename must not be allowed to answer that question by
+  accident.'
+created: '2026-09-21T00:00:00Z'
+updated: '2026-09-21T00:00:00Z'
+```