PostgreSQL 18 restore verification

Release 0.1.0a41 makes one narrow change to taskq db verify: it accepts the equivalent taskq.schedules constraint form that PostgreSQL 18 can produce when reparsing a pg_dump / pg_restore copy. The restored table still must have the expected 21 constraint identities and definitions. The verifier accepts only the canonical relation digest or the one known alternate digest; all other catalog, migration, target-identity, role, ownership, and grant checks remain exact. A different result fails closed.

The SQL contract remains 0.6.12, Protocol document revision 1.0.18, and packaged migrations 0001–0048. There is no change to queue, worker, scheduler, HTTP, or authorization behavior. Existing a40 runtimes remain compatible and do not need an upgrade just to validate the restore.

Restore acceptance

1. Install the exact published a41 artifact in the operator environment.
2. Reconcile schema and object ownership and grant provenance separately, particularly if the dump was restored with --no-owner --no-acl.
3. Run taskq db verify against the intended target using an administrative credential and explicit context or target identity.
4. Require all 18 packaged verification checks to pass. Investigate any remaining mismatch; do not treat this exception as a general drift waiver.

taskq --context restored-target db verify

See the a41 release record for the exact digest allowance and validation scope. Follow the runtime-first sequence when a separate release changes the SQL contract.