Settle the npm lane field, and record an ungoverned duplicate

The attended session enumerated field names at the governed path: NPM_AUTH_TOKEN
is the only field present, at KV version 2. This repository's record was correct.
secrets-engine's lowercase field name and the ops-warden catalog change made on
that statement both name a field absent from that path, so that change points the
front door at nothing and must be reverted before next use. The both-fields
reconciliation is ruled out.

The same session found the legacy path is real: secret/coulomb/whynot-design/
npm/publish exists at version 1, created five days after the governed lane was
verified, outside its policy and outside any CCR. Only metadata was read; field
names were not enumerated and nothing was deleted. Disposition is the new
RPF-WP-0035-T07, which asks first whether the consumer's proven publish has been
reading the duplicate rather than the governed lane.

Receipt carries field names only, attended_identity true, no mutation.

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

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1275505@bnt-lap001
Assistant-Session: 97265baa-f08f-4032-b290-a1e2965a69c5

workplans/RPF-WP-0035-credential-lane-implementation.md

@@ -242,6 +242,45 @@ Neither Warden fetch selector is resolvable through these verifier-only CCRs.
 Do not re-request the completed two named reviews or reseed these paths.
 Rotation is a distinct, version-guarded operation.
 
+## Dispose of the ungoverned whynot-design npm duplicate
+
+```task
+id: RPF-WP-0035-T07
+status: todo
+priority: high
+```
+
+Found by the attended session on 2026-09-10 while settling the npm field
+question. `secret/coulomb/whynot-design/npm/publish` exists at version 1,
+created 2026-07-03T15:00:44Z and never updated — five days after the governed
+lane at `platform/workloads/coulomb/whynot-design/npm-publish` was verified
+(CCR-2026-0001, 2026-06-28). It sits outside that lane's exact-path policy and
+outside any CCR here. Receipt:
+`docs/evidence/2026-09-10-npm-lane-field-resolution.json`.
+
+Only metadata was read. Its field names were not enumerated, its value was not
+read, and nothing was deleted — a location holding real credential material is
+disposed of deliberately, not tidied away in the session that found it.
+
+The likely explanation, unconfirmed: secrets-engine reports the lane's field
+under a lowercase name that is absent from the governed path, and their catalog
+declares this legacy location. If their proven pilot publish read from here,
+then a working production lane has been running off an ungoverned duplicate,
+and the governed lane's acceptance evidence describes a path the consumer does
+not use. That is worth establishing before anything is removed.
+
+**Unblock:** secrets-engine confirms which location their publish actually reads
+and whether the two hold the same value; the owner of the legacy path is
+identified; and a metadata-or-field-name read of the legacy path is admitted so
+the duplicate can be characterised without reading its value.
+
+**Done when:** the legacy path's provenance and consumer are established, the
+governed lane is confirmed as the one in use or the consumer is moved to it as a
+reviewed lane change, the duplicate is destroyed or brought under a CCR with an
+owner, and the disposition is recorded. If the value proves to be live and
+ungoverned, treat it as an exposure with the same custody rules as RPF-WP-0027:
+never record the value, fingerprint, length or shape.
+
 ## Admit the separate approval client-side readers
 
 ```task