feat(provider): add MigrationPolicy / ProviderConfig for VerifyOnly construction

[pinodeca]

Introduces a ProviderConfig / MigrationPolicy API for PostgresProvider construction, with related safety hardening for the migration path. Backend processes that must not run DDL can construct with MigrationPolicy::VerifyOnly; the existing default (MigrationPolicy::ApplyAll) preserves today's behavior.

VerifyOnly does not take the migration advisory lock and does not create or modify any database objects, eliminating per-connection lock contention and DDL-grant requirements for backend processes.

Commits

715ec60 feat(provider): add MigrationPolicy / ProviderConfig for VerifyOnly construction

The original PR commit. Introduces MigrationPolicy { ApplyAll, VerifyOnly }, ProviderConfig, and the new constructor surface. ApplyAll is the default and preserves pre-feature behavior across new, new_with_schema, and the Entra constructors. VerifyOnly verifies that _duroxide_migrations exists in the target schema and that every bundled migration has been applied, returning an error otherwise.

17898d0 feat(migrations): reject unknown applied migrations

Closes a foot-gun where an older binary could silently rewrite a database that is ahead of its code. MigrationRunner now refuses to proceed when the tracking table records versions the running binary does not bundle:

• Under ApplyAll the check runs under the migration advisory lock and before any DDL, so a downgrade can never half-rewrite an ahead-of-code schema. The error names the unknown versions and instructs the operator to update the code.
• Under VerifyOnly the same check runs as part of verification.

92d476c refactor(provider)!: collapse constructors into new_with_config

API cleanup before stabilizing the new surface. Collapses the various *_with_config and Entra-specific constructors into a single PostgresProvider::new_with_config(ProviderConfig). ProviderConfig now carries the connection variant via a new ConnectionConfig enum (Url(String) or Entra { host, port, database, user, options }), the optional schema name, and the migration policy.

Construct via ProviderConfig::url(database_url) or ProviderConfig::entra(host, port, db, user, options) and adjust fields as needed. The previous URL/Entra constructors are kept as #[deprecated] shims that delegate to new_with_config, so callers on 0.1.x source paths continue to compile. Breaking only for the unreleased new_with_config(url, cfg) shape introduced in 715ec60.

859b062 feat(provider)!: validate schema names

Adds a conservative validator (^[A-Za-z_][A-Za-z0-9_]*$) called from new_with_config — the single entry point all other constructors now delegate to.

PostgreSQL identifiers cannot be bound as SQL parameters, so the schema name is interpolated directly into the DDL and DML the provider issues (CREATE SCHEMA {schema}, INSERT INTO {schema}._duroxide_migrations ..., etc.). Without validation, a caller that forwards attacker-controlled input as schema_name would have a SQL injection vector. PostgreSQL's full identifier grammar is broader; this validation is intentionally conservative. Already-shipped releases (<= 0.1.33) are unaffected; the break is on unreleased API surface only.

d5d1619 test(provider): port remaining opt initialization tests

Pure additive. Adds four integration tests against the new API covering provider-initialization paths that were previously implicit:

• verify_only_errors_when_schema_missing — VerifyOnly against a database where the target schema does not exist at all.
• verify_only_errors_when_tracking_table_missing — VerifyOnly against a bare schema (CREATE SCHEMA was run, but no migrations applied).
• verify_only_errors_when_migrations_behind — VerifyOnly against a schema whose tracking table is missing the most recent bundled migration; the error names the missing version.
• concurrent_apply_all_is_serialized — two concurrent ApplyAll initializations against the same fresh schema must both succeed, exercising the migration advisory lock end-to-end.

Squash strategy

Commits stay split for review. At merge time they squash cleanly along two seams: 17898d0 is a self-contained safety fix, and 92d476c + 859b062 form one breaking-API commit. d5d1619 is pure tests and can squash with either of the above. Happy to reorganize before merge if preferred.

Tests

• cargo fmt --check ✅
• cargo clippy --tests ✅ (no new warnings on touched code; pre-existing warnings in session_e2e_tests and src/provider.rs:3121 are unrelated)
• cargo test --test migration_policy_tests ✅ (10 passed)
• Library tests (cargo test --lib) ✅
• Regression / concurrent-migration / cached-plan-retryable tests ✅

[pinodeca]

Findings by GPT-5.5:

• P1: VerifyOnly can accept a schema with no runtime tables.
  In duroxide-pg/src/migrations.rs, verify() only checks that _duroxide_migrations exists and contains every embedded migration version. It never checks that the actual provider tables still exist. That matters because migrate_inner() already has a repair path for exactly this corrupted state, “migration marked applied but tables don’t exist,” via check_tables_exist() in duroxide-pg/src/migrations.rs. With VerifyOnly, the same schema would construct successfully and then fail later on normal provider operations with missing relation/function errors. Add a VerifyOnly check for at least the key tables, and ideally the required stored procedures too. A focused regression would be: apply migrations, drop instances, then assert VerifyOnly fails.

• P2: The new schema-name validator accepts identifiers that the unquoted SQL path does not handle consistently.
  duroxide-pg/src/provider.rs allows uppercase schema names via ^[A-Za-z_][A-Za-z0-9_]*$, but all schema references are emitted unquoted. PostgreSQL folds unquoted MySchema to myschema, while the migration verifier checks information_schema.tables.table_schema = $1 using the original mixed-case string in duroxide-pg/src/migrations.rs and duroxide-pg/src/migrations.rs. Result: ApplyAll can create/use myschema, but VerifyOnly against MySchema reports the migration table missing, and a later ApplyAll can think tables are absent and try to reapply migrations. Either canonicalize accepted schema names to lowercase before storing them, or reject uppercase identifiers. Reserved words are a related edge case for the same reason: they pass validation but can fail in unquoted SQL.

Notes

I did not run tests, per your request. The new test suite covers the main migration-policy paths well, but it currently misses both “tracking table present, runtime tables absent” and mixed-case schema-name behavior.