08 - BLOCKER H: ACL Snapshot Execution-Order Fix

Codex recheck finding

The ACL snapshot completeness additions were accepted, but only WITH an execution-order dependency: the snapshot is meaningful for rollback only if captured BEFORE the ownership transfer, and effective-privilege verification must occur AFTER owner transfer + revoke. The prior blueprint captured the snapshot at S16 (the owner/ACL cutover step), which is too late once the executable routine ownership moves at S15.1. Effective-privilege guards must also explicitly disposition superuser roles. (Codex recheck CHECK_E ACCEPTED_WITH_EXECUTION_ORDER_DEPENDENCY.)

The fix - snapshot before transfer, verify after (docs 04, 05, 06, 07)

• Snapshot moved to S14 (pre-cutover), BEFORE the S15.1 owner transfer. PKG-E captures the complete effective-privilege ownership/ACL snapshot as a mandatory output; PKG-F's precondition is that this snapshot is present, hash-bound, read-back-verified, and restore-rehearsed. PKG-G does NOT re-capture it (after S15.1, directus has already lost ownership of the executable routines, so a fresh snapshot would record the post-transfer state and could not restore the original owner).
• Snapshot includes owner and role membership (unchanged from the accepted additions): owner (relowner/proowner), relacl/proacl, pg_attribute.attacl column ACL, sequence ACL, nspacl, pg_default_acl, and pg_auth_members-expanded effective privilege, plus snapshot_sha256.
• Replay/rollback distinguishes owner transfer from grants. The S15 rollback restores the prior owner (directus) AND the captured ACL by replaying the S14 snapshot; the two are separate restore actions (owner via ALTER ... OWNER, grants via GRANT/REVOKE).
• Effective-privilege verification occurs AFTER owner transfer + revoke. G-NOLEGACY-POST (S15.3) and G-OWNER-CUTOVER (S16) compute effective EXECUTE/DML over non-superuser, non-owner roles, both-direction (pre→post and post→pre), role-membership-aware.
• Superuser disposition. The cluster superuser workflow_admin (rolsuper/rolbypassrls) is excluded from every "revoked-to-zero" claim and recorded as an accepted out-of-band property - it cannot be made privilege-zero by object ACL changes.
• S15/S16 ordering matches PostgreSQL semantics. Snapshot (S14) → owner transfer (S15.1) → revoke (S15.2) → effective-privilege verify (S15.3) → activate+repoint (S15.4) → remaining relation/ACL cutover (S16). (doc 05 invariant 3; doc 04 §S14/§S15/§S16.)

Self-check

PASS only if the snapshot precedes ownership transfer, captures owner + role membership, distinguishes owner transfer from grants in replay, verifies effective privilege after transfer+revoke, and matches PG semantics. PASS - snapshot at S14 before S15.1; owner + pg_auth_members included; rollback restores owner and grants separately; verification is post-transfer/post-revoke and superuser-aware.