Shared SQL helpers for the versioned Postgres migration chain.

Centralizes the prefix-sensitive patterns that individual version modules used to hand-roll (and get subtly wrong in independent ways):

• qualify_table/2 — schema-qualified table reference for raw SQL in NEW migration code (existing versions keep their local helpers; migrating them is opportunistic). Index names must stay bare on CREATE INDEX (Postgres rejects CREATE INDEX schema.name); only DROP INDEX schema.name accepts a qualified name.
• validate_prefix!/1 — rejects prefixes that can't be interpolated into SQL safely. Called at the up/down entry points and by the prefix-resolving tooling (PrefixConfig.resolve_prefix/1, Install.Common).
• ensure_extension!/1 — privilege-aware replacement for a bare CREATE EXTENSION IF NOT EXISTS. Postgres checks the CREATE privilege before the IF-NOT-EXISTS short-circuit, so the bare statement fails for low-privilege roles even when the extension is already installed. This helper checks pg_extension first and only attempts creation when the extension is genuinely missing.
• ensure_uuid_v7_function/1 — creates uuid_generate_v7() inside the install's schema (never wherever search_path happens to point, which pollutes public and fails outright on PG15+ where public isn't world-writable). Unlike ensure_extension!/1, this one does NOT pre-check existence — it queues CREATE OR REPLACE FUNCTION for every install whose role owns (or could own) the function. That is deliberate, not a missed optimization: an unless already exists guard here (the original shape) meant a function created before some later fix to this same body (e.g. the pgcrypto schema-qualification change) stayed on the OLD body forever — CREATE OR REPLACE never got a chance to run because the guard always saw "exists" and skipped it, and there was no other path back to a correct body short of a manual DROP. CREATE OR REPLACE FUNCTION on an unchanged signature is additive and idempotent (no dependent objects break, nothing is dropped), so the guard bought nothing but a stuck body — removing it is what lets PhoenixKit.Migrations.Repair self-heal a drifted body via this same helper instead of reporting a permanent, un-fixable finding. The one case still checked first is an existing function owned by another role: CREATE OR REPLACE requires ownership, and in migration context the statement is only QUEUED, so that failure arrives at flush time where no rescue here can reach it and the migration aborts. That topology is documented and supported (PhoenixKit.Migration's moduledoc tells a DBA to pre-create the function), so it is excluded before the statement is queued.

Functions without a repo argument run in Ecto.Migration context (immediate existence checks via repo().query/3, DDL queued via execute/1). The repo-taking variants are for runtime callers outside a migration context, e.g. mix phoenix_kit.repair.