Decide and implement federation denied-audit parity for NP-29

[jeremi]

Follow-up from #200 and #321.

release/notes/negative-path-coverage-map.md marks NP-29 as Partial. Current tests cover disabled-route behavior, invalid JWS denial, replay denial, no-source-read denials, and signed stale-source errors with audit redaction. The remaining blocker is complete denied-audit context parity for post-verification federation denials.

Current gap to decide:

Denied outcomes do not carry every peer/profile/purpose/JTI/subject-hash field that success and signed-error outcomes can carry. Release sign-off needs either parity coverage or an explicit maintainer-approved deferral.

Implementation DoD if this is closed by code:

• Post-verification federation denials populate the agreed redacted/hashed audit context consistently with success and signed-error outcomes.
• Denied audit records do not include raw sensitive request fields.
• Denials still happen before source read or signed success wherever the map claims that property.
• Tests assert replay, denylisted/unknown key, no-source-read, and signed-error denial audit behavior as applicable.
• Existing federation success and signed-error audit behavior remains unchanged.
• release/notes/negative-path-coverage-map.md is updated with named test anchors and an accurate disposition.

Verification expected:

• Focused registry-notary-server federation HTTP tests.
• Relevant workspace format, clippy, and tests required by the repo gate.