A normal secret-store read still pairs a DCR client secret with a different client after a repeated hand-off (owner stamp unchecked on read) #2768

Found during the v2.12.0 release smoke (#2764), while verifying #2734 / PR #2739.

Problem

#2739 adds an owner stamp (…#owner, holding a client_id plus a MAC keyed by the value) beside each DCR client_secret / registration token. It also makes carries trust only that stamp. The ordinary read path does not consult the stamp, and the file-to-keychain hand-off (absorbFileSecretsIntoKeyring) is unchanged by design. So after the #2734 sequence, the live keychain namespace already pairs one client's secret with another client before any re-adoption or carry runs.

1. Client A is registered, and its secret is absorbed into the keychain.
2. The state file re-registers client B under the same namespace.
3. The next hand-off keeps the existing keychain value (A's secret, whose stamp correctly names client-a).
4. A normal read of the stamped file on the keychain now returns:

{"client_id":"client-b","client_secret":"secret-a"}

The output is the same on c1365148 (before #2739) and on the v2.12.0 merge tree. That makes it pre-existing and outside #2739's stated scope, not a regression. #2739's carry correctly refuses this pairing; the read does not.

Impact

A confidential DCR client in this state authenticates with the wrong secret (an invalid_client at the token endpoint) until it re-registers. It requires a repeated hand-off with a re-registration in between, which is a narrow path, but the failure is silent until the token request.

Expected

On read, a DCR secret whose stamp vouches for the value (MAC valid) but names a different client_id than the one the state file holds is treated as absent, not paired. The read then behaves as it would for a client with no stored secret. A value with no valid stamp (legacy, or rewritten by an older Inspector) keeps today's behavior, matching #2739's "purged as before, not guessed at" stance on unstamped values.

Evidence

Driven with a probe calling the real core/auth/node functions on real files (oauth.json, the namespace ledger, secrets.json) against a file-backed fake of @napi-rs/keyring, with no real keychain touched. It staged the #2734 repeated-hand-off repro from clients/web/src/test/integration/auth/node/oauth-secrets-namespace.test.ts. A regression test for the fix belongs in that integration file.