notary: consolidate correctness-store plumbing after the PostgreSQL cutover

[jeremi]

Use Case

Review of #364 found several low-risk internal drift points in the completed Notary PostgreSQL cutover. None is reachable as a current correctness failure, and expanding the migration PR would make the release-critical state change harder to audit. They should be cleaned up together after 1.0 while the product-owned domain boundaries remain fresh.

Proposed Behavior

• Encode the CredentialStatusStore backend choice so an in-memory state-plane handle cannot be attached to its PostgreSQL path.
• Replace the two locally divergent 32-byte pseudonym hash decoders with one strict audited helper without widening accepted prefixes or case.
• Add bounded observability when batch-owner Drop cleanup cannot schedule batch_fail_v1.
• Eliminate the batch-evaluation Value to String to Value round trip.
• Let the store own PostgreSQL synthetic idempotency-key routing instead of leaking backend identity into the evaluator.
• Collapse repeated domain-session acquisition only where a typed helper produces net deletion and preserves each domain error.
• Have the Rust sensitive-state probe expose the non-secret key identifier used by conformance so the shell harness does not reimplement the KDF in Python.

Acceptance

• Existing PostgreSQL and in-memory semantics remain byte-for-byte or behaviorally identical.
• Focused negative tests cover impossible backend wiring, hash grammar, Drop fallback, and batch routing.
• The Notary PostgreSQL 16, 17, and 18 conformance matrix remains green.
• The change reduces net code and does not add a new public API or configuration key.

Boundaries

• No schema, migration, retention, transaction, readiness, or HTTP contract changes.
• No shared Relay/Notary tables or state semantics.
• Do not introduce a generic store, persistence, or state framework.