Decide and implement STS denial-audit parity for NP-23

[jeremi]

Follow-up from #200 and #321.

release/notes/negative-path-coverage-map.md marks NP-23 as Partial. Current coverage pins no-mint behavior for mapped STS exchange denials, and the HTTP token endpoint has response-shape coverage for a binding denial. The remaining blocker is denial-audit parity: the public STS audit interface currently records token-mint events only through StsAuditSink, so release sign-off needs a maintainer decision and implementation path.

Decision needed:

• Add an STS denial audit event and test it, or
• Approve an explicit 1.0 deferral with rationale and keep the release map honest.

Implementation DoD if this is closed by code:

• STS denial paths record a denial audit event without subject-token, access-token, or credential material.
• The denial audit event carries only stable/redacted context needed for operations and review.
• Tests cover wrong resource, unsupported requested_token_type, invalid subject token, missing sender/session binding, and the HTTP token endpoint denial path as applicable.
• The chosen sink-failure policy for denial audit is explicit and tested.
• Existing token-mint audit behavior remains unchanged.
• release/notes/negative-path-coverage-map.md is updated with named test anchors.

Verification expected:

• Focused registry-platform-sts tests for exchange denial audit behavior.
• Relevant workspace format, clippy, and tests required by the repo gate.