A half-provisioned tenant schema fails seven changes' verify scripts

[perigrin]

Found while probing #324's migration in the round-7 review. Pre-existing and out of that PR's scope.

A tenant row whose schema exists but is empty (no tables) makes sqitch verify fail hard for seven changes: events-and-sessions, fix-tenant-workflows, payments-amount-cents, refund-amounts-cents, payments-typed-obligation, and two others — seven errors in a single run.

enrollment-reenrol-after-drop is the one that stays ok, because its loop guards with both information_schema.schemata and to_regclass(format('%I.enrollments', s)). Schema existence is not table existence, and only the second guard catches that.

The fixture is trivially reproducible now: create a tenant row and its schema without running clone_schema.

Worth fixing because sqitch.conf sets [deploy] verify = true, so any of these can block a deploy on a database that has one half-provisioned tenant.

[perigrin]

Related gap found in the round-8 review, same area.

t/database/migration-verification.t cannot exercise any migration's tenant loop at all. Its database contains only the registry and registry-platform tenants and no cloned tenant schema, so both the deploy loop and the verify loop hit their CONTINUE on the first iteration and do nothing.

Demonstrated by mutation: breaking the tenant copy of a predicate in sql/deploy/enrollment-reenrol-after-drop.sql left migration-verification.t ..... ok while the identical mutant made t/database/enrollment-reenrol-tenant.t's deploy die.

So every scrap of tenant-side verify coverage in the suite rests on that one file — and only incidentally, because sqitch.conf sets [deploy] verify = true, so its deploy_to helper runs verify as a side effect rather than by intent.

Every migration with a per-tenant loop is therefore ungraded on the tenant side unless someone remembers to write a dedicated test. Given clone_schema renames indexes and constraints, the tenant path is exactly the one most likely to be wrong.

Worth fixing together with this issue, since both are about tenant schemas being under-represented in migration tests: give migration-verification.t a properly clone_schema-provisioned tenant (which also gives this issue's half-provisioned case a natural sibling fixture).