[Kiran01bm]

One integration test walks the irreversible-operations registry against a real server and proves each entry is refused without its acknowledgement, rejected when the acknowledgement names another table, and leaves the table untouched either way.

Why

#282 added the registry and a unit test that it is complete, but that test checks the registry's shape, not the gates. Each gate has its own integration tests, written separately and asserting different things. Nothing ties a registry entry to evidence that its gate holds, so an entry could claim --force gates an operation while the gate itself is broken.

What

• TestIrreversibleOperationsAreGated (pkg/migrate/irreversible_registry_integration_test.go) gives every registry entry a real statement against a fresh orders table, with every other gate open so only the entry's own acknowledgement decides the outcome.
• Without the acknowledgement, the verdict is refused with the entry's declared reason. The restart entry is skipped here: without it the run resumes.
• With the acknowledgement naming another table, Run returns a usage error and a zero verdict.
• Either way, nothing ran: the table's columns, constraints, indexes, and index storage files are unchanged, no copy-and-swap checkpoint was written, and the table still takes inserts.
• A registry entry without a scenario, or a scenario matching no entry, fails the test.

Test only; no behaviour change.

Before / after

Suppose a change breaks the force acknowledgement check so it accepts any table name, and an operator runs ALTER TABLE app.orders ADD COLUMN nickname text UNIQUE with --force app.customers.

Before
  registry says: "submitted form that blocks the table" is gated by --force
  TestIrreversibleOperationRegistryIsComplete   passes  (the registry's shape is fine)
  the broken check lets --force app.customers through
    ADD COLUMN ... UNIQUE runs under the table's lock   ── nothing in CI ties the entry to its gate

After
  TestIrreversibleOperationsAreGated / submitted form that blocks the table
    runs the statement with --force app.customers
    expects a usage error and an unchanged table
    finds the nickname column and its index   ── FAIL

Stacked on #282; retarget to main once it merges.