make control file unneeded and a part of a built step leveraging a dist/ analog

[pyramation]

this will also free up our namespace issues with control files / extensions having to match package names.

[pyramation]

Right now LaunchQL uses a single control file, which forces all changes (including test-only logic) into the same deployment boundary. Moving toward separate sections or multiple control files would let us introduce something like devDependencies in npm:

• Allow verify scripts, test helpers, and “Supabase-core-style” migrations to exist without being deployed to production.
• Keep production deploys clean by excluding dev/test-only SQL.
• Enable richer local testing workflows without polluting the runtime migration plan.

This would give LaunchQL a clean separation between:

• Prod migrations
• Dev/test migrations
• Verify scripts / testing scaffolds

…and unlock a more modular, npm-style workflow for Postgres projects.