Introduz ADAPTER_ENV e endurece configuração e infraestrutura

`next start` força NODE_ENV=production, então homologação não tinha como se
distinguir de produção: o login local ficava desligado (correto) e o módulo
exigia o SSO do Elo Pro, que ainda não existe. Não havia terceiro caminho.

- `ADAPTER_ENV` com development, staging e production, independente de
  NODE_ENV. Toda política passa a derivar dele.
- Fail-fast de configuração em `fail-fast.ts`, separado de `env.ts` porque
  `process.exit` não existe no Edge Runtime.
- `requireDatabaseUrl` elimina o fallback silencioso para PGlite: um segredo
  ausente em staging migrava um arquivo local e parecia sucesso.
- Shim de identidade passa a ser decisão explícita via
  `ADAPTER_APPLY_IDENTITY_SHIM`; aplicá-lo sobre o schema real do Elo Pro é
  destrutivo em potencial.
- `migration-manifest.ts` responde o estado do schema consultando só o banco.
  Ler o diretório numa rota fazia o Next tracear o projeto inteiro para a
  saída standalone, levando docs, testes e fontes para a imagem.
- Redis e Supabase viram singleton por processo. Criar um ioredis por
  requisição vazava conexão: o cliente é lazy, abre no primeiro uso e nunca
  fecha.
- Namespace de chaves deriva de ADAPTER_NAMESPACE e do ambiente lógico, não
  de SENTRY_ENVIRONMENT. Observabilidade e isolamento de dados são decisões
  diferentes, e a variável única fazia homologação e produção colidirem.
- Listagem do bucket passa a paginar e descer em subpastas. Parando em 1000
  entradas, a limpeza por TTL deixava de ver arquivos e temporários venciam
  sem nunca ser removidos.
- `ping` e `hit` no coordenador, e `healthcheck` no armazenamento, para o
  health check tocar as dependências de verdade.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

src/infra/db/migration-manifest.ts

@@ -0,0 +1,39 @@
+import { identityShimEnabled } from "@/config/env";
+import type { Db } from "./types";
+
+/**
+ * Migrations que **este build** espera encontrar aplicadas.
+ *
+ * É uma lista estática de propósito. O health check e o worker precisam
+ * responder "o banco está na versão que este código espera?", não "o banco
+ * combina com os arquivos que por acaso estão no disco". Ler o diretório aqui
+ * também fazia o Next tracear o projeto inteiro para dentro da saída
+ * `standalone`.
+ *
+ * `migrate()` confere que esta lista e o diretório `migrations/` não divergiram.
+ */
+export const EXPECTED_MIGRATIONS = [
+  "0001_platform_shim.sql",
+  "0002_spreadsheet_adapter.sql",
+  "0003_rls.sql",
+  "0004_audit_append_only.sql",
+] as const;
+
+/** Migrations que criam o shim local de identidade do Elo Pro. */
+export const SHIM_MIGRATIONS: ReadonlySet<string> = new Set(["0001_platform_shim.sql"]);
+
+export function isShimMigration(file: string): boolean {
+  return SHIM_MIGRATIONS.has(file);
+}
+
+export type PendingOptions = { applyIdentityShim?: boolean };
+
+/** Migrations esperadas que ainda não constam em `schema_migrations`. */
+export async function pendingMigrations(db: Db, options: PendingOptions = {}): Promise<string[]> {
+  const applyShim = options.applyIdentityShim ?? identityShimEnabled();
+  const appliedRows = await db
+    .withService((query) => query.query<{ id: string }>("select id from public.schema_migrations"))
+    .catch(() => [] as { id: string }[]);
+  const applied = new Set(appliedRows.map((row) => row.id));
+  return EXPECTED_MIGRATIONS.filter((file) => !applied.has(file) && (applyShim || !isShimMigration(file)));
+}