Fix prefixed migrations + tooling for low-privilege multi-schema installs

[mdon]

Follow-up to #628, driven by a field report from a hardened multi-schema install (schema pre-created by a DBA and owned by the app role, no CREATE on the database, PG 15+ non-writable public, PgBouncer). The report confirmed #628's index/existence-check fixes and surfaced five more bug families — all reproduced against source and fixed here, plus three adjacent bugs found while verifying.

Migration chain

• CREATE EXTENSION / CREATE SCHEMA fail on privilege before the IF-NOT-EXISTS short-circuit. All five extension sites (V01 citext, V26/V40 pgcrypto, V111 pg_trgm, UUIDRepair) and V01's schema creation now check pg_extension / information_schema.schemata first and only attempt creation when the object is genuinely missing. A missing extension that the role cannot create raises an operator-facing message listing the three required extensions (also documented in PhoenixKit.Migration's moduledoc for DBAs to pre-provision).
• V27 dropped the caller's create_schema flag at the Oban handoff — Oban.Migration.up(prefix: prefix) re-defaults it to true for any non-public prefix and executed the failing CREATE SCHEMA mid-chain (the report's "dies around v27–v31"; queued SQL surfaces at a later flush). V27 now passes create_schema: false — by V27 the schema always exists, V01 owns creation.
• uuid_generate_v7() was created unqualified — it landed wherever search_path pointed, polluting public on prefixed installs and failing outright where public isn't writable. The function is now created inside the install's schema (all 4 creation sites + UUIDRepair) and all ~89 call sites across 35 files (DEFAULTs, backfill UPDATEs, fragment/1) are schema-qualified. For upgrade chains starting ≥ V40 (which skip the creation sites), Postgres.up/1 re-ensures the function at the prefix before running steps. Existing installs are unaffected: existing columns keep their OID-pinned defaults; the ensure step only creates the function where missing (never REPLACEs a function owned by someone else).
• The prefix is now validated at the up/down entry points ([a-z_][a-z0-9_]*) — it's interpolated into hundreds of statements, mostly unquoted, so anything needing quoting only ever half-worked.
• New PhoenixKit.Migrations.Postgres.Helpers centralizes these patterns (qualify_table/2, uuid_v7_call/1, ensure_extension!/1-2, ensure_uuid_v7_function/1-2, validate_prefix!/1) — the per-version hand-rolled helpers were exactly why Fix prefixed migrations: schema-qualified index names + cross-schema existence checks #628's index bug existed in four independent places. Migrating old versions to it is opportunistic; new code should use it.

Tooling

• mix phoenix_kit.install --prefix X now persists config :phoenix_kit, prefix: "X" (new PhoenixKit.Install.PrefixConfig) — the migration docs always told hosts to add it, but nothing did, so update/status looked at public and reported a prefixed install as "Not installed".
• update/status/gen.migration resolve the prefix as --prefix → config :phoenix_kit, :prefix → "public".
• Install.Common no longer fabricates {:current_version, 1} from the mere existence of migration files when the DB has no marker at the prefix — that fallback made mix phoenix_kit.update generate a from-scratch v01→v142 migration into the wrong schema (the report caught it by eye before running it). The not-installed notice now names the resolved prefix and hints at --prefix/the config key.
• Update-migration generators always emit create_schema: false — updating implies the schema exists. Also fixed: MigrationStrategy hardcoded "public" when version-checking an existing install, and migration_opts/2 silently dropped --create-schema=false (omitting the key let the chain re-default it to true).
• Repo auto-detection refuses to silently pick among multiple detected Ecto repos (the report's project had a migration-only CoreRepo that got wired into config :phoenix_kit, repo:); it now lists them and requires --repo.

Verification

• test/integration/prefix_migration_test.exs extended: asserts uuid_generate_v7 lives in the prefixed schema and uuid DEFAULTs are pinned to it. Full chain into a scratch schema passes.
• Fresh public install from a dropped DB: full v01→v142 clean (extension-creation path exercised).
• The report's exact repro (section D) now passes end-to-end: role with no superuser and no database CREATE, pre-created schema, pre-provisioned extensions → full v01→v142 chain, marker 142, function + Oban tables in the prefix, zero objects created in public.
• New unit tests for Helpers (prefix validation, qualification) and PrefixConfig.resolve_prefix/1.
• mix precommit clean; full suite failures identical to the pre-existing multi-session/sitemap/settings set (verified by stash-rerun on the same base).

Notes for the reviewer

• The report flags two correct qualified-name sites — uuid_fk_columns.exdrop_uuid_fk_index/4 and V56 drop_uuid_unique_indexes (DROP INDEX schema.name is valid) — deliberately untouched.
• Known gap, out of scope: runtime code never reads config :phoenix_kit, :prefix — Ecto queries run unprefixed, so prefixed installs still need the DB role's search_path to include the schema (the report's setup relied on this). Documented in AGENTS.md.
• This branch also carries two earlier local commits: the daisyUI advisory-warning approach (vendored-plugin custody replaced by install/update/doctor version warnings) and an AGENTS.md refresh.