notary: factor repeated static migration validation helpers

[jeremi]

Use Case

The Notary PostgreSQL migration introduced by #356 deliberately keeps product-owned, statically inspectable SQL. Review found two smaller validation fragments that are duplicated byte-for-byte: the subject-access quota request-shape validation in debit and check functions, and the preauthorization generation-mismatch guard in reservation functions.

The nine retention DELETE blocks are intentionally not in scope. Their key shapes and cutoffs differ, and replacing static SQL with dynamic EXECUTE would reduce auditability.

Proposed Behavior

• Extract only byte-identical subject-access request validation into one typed PL/pgSQL helper.
• Extract only the shared preauthorization generation-mismatch check where the resulting helper keeps table and authority boundaries explicit.
• Retain static per-domain mutations and existing SECURITY DEFINER search_path, owner, EXECUTE, and fingerprint attestation.
• Regenerate the semantic and catalog fingerprints deliberately.

Acceptance

• PostgreSQL 16, 17, and 18 conformance, logical upgrades, backup/restore, and negative role/catalog checks pass.
• Every failure code and transaction boundary remains unchanged.
• The final SQL is shorter and at least as easy to audit.

Boundaries

• Post-1.0 maintainability cleanup, not a migration blocker.
• No dynamic SQL for retention or table selection.
• No generic state framework and no Relay schema reuse.