Verify code, ledger, provider setup, and live behavior before promoting an excluded integration

Promote a deliberately excluded integration only after checking four separate layers: reviewed code, exact migration ledger and schema, provider registration and runtime configuration, and a real-user side-effect test. Passing branch CI covers code and disposable schema behavior; it does not prove production readiness. When an additive migration's timestamp predates versions already applied, compare the live ledger with the reviewed migration files and dry-run the exact pending set before applying it while services are up. This method applies to notification and OAuth rollouts with application-owned tables; it does not decide whether the integration should be enabled, and a provider callback or delivery still needs live acceptance.

Evidence/example (2026-09-15): Supabase's database migration guide describes the separate Git files and supabase_migrations.schema_migrations history and recommends listing discrepancies before repair; the CLI reference documents db push --dry-run and the timestamp-based migration list. The four-layer release gate is an inference from the rollout dependencies, not a claim from Supabase documentation. No organization configuration or access state is included.