Corrige quatro defeitos de runtime do worker e dos scripts operacionais

Os quatro apareceram ao exercitar o layout de runtime da imagem — apenas
node_modules de produção, src, scripts e migrations — e nenhum aparecia na
suíte de testes nem no build. Os dois primeiros formavam uma armadilha mútua.

1. O CLI do `tsx` cria processo filho (PIDs medidos: 20840 contra 21096).
   O SIGTERM do `docker stop` pararia no pai, o worker nunca rodaria o
   handler, o lock esperaria o TTL de 120s e o `stop_grace_period` só
   atrasaria um SIGKILL. Passa a ser `node --import tsx`, mesmo processo.
2. Top-level await nos scripts falha com `--import tsx`, porque sem
   `"type": "module"` o esbuild gera CJS. `migrate`, `worker`, `seed-staging`,
   `flag`, `cleanup` e `check-bucket` não executariam: a migração não rodaria
   e o worker não subiria. `runScript`/`runWithDb` resolvem sem mudar o
   module type do projeto.
3. `import "server-only"` em `worker-loop.ts`: o pacote lança fora do bundler
   do Next, e o worker morria no start.
4. `@react-pdf/renderer` carregado no import de `process-job.ts` falha com
   ERR_PACKAGE_PATH_NOT_EXPORTED ao resolver a hifenização fora do bundler,
   derrubando worker e cleanup. O PDF sai sob demanda no download, então o
   import passou a ser tardio, dentro do ramo que o usa.

Além disso:

- O loop do worker saiu do script para `worker-loop.ts`, testável sem subir
  processo. O script cuida só de sinais, cadência e bootstrap.
- Desligamento gracioso espera o tick corrente para o `finally` liberar o
  lock. Um job que ainda não começou fica `queued`: nada pela metade.
- Heartbeat por tick, lido pelo healthcheck do contêiner. Processo vivo mas
  travado passa em qualquer verificação de PID.
- O worker recusa iniciar com migration pendente, e relê o contexto do dono a
  cada job: papel e feature flag podem ter mudado desde o enfileiramento.
- `verify-config`, `check-bucket`, `seed-staging` e `smoke-staging` novos. O
  smoke tem fase autenticada que só roda com credencial fornecida pela
  operação e, sem ela, reporta PENDENTE em vez de aprovado.

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

scripts/migrate.ts

@@ -1,10 +1,28 @@
-import { createFileDb } from "../src/infra/db/pglite";
-import { createPostgresDb } from "../src/infra/db/postgres";
-import { migrate } from "../src/infra/db/migrate";
-import path from "node:path";
+import { identityShimEnabled } from "../src/config/env";
+import { migrate, pendingMigrations } from "../src/infra/db/migrate";
+import { bootstrapScript, describeTarget, runWithDb } from "./_bootstrap";
 
-const databaseUrl = process.env.DATABASE_URL;
-const db = databaseUrl ? createPostgresDb(databaseUrl) : await createFileDb(path.join(process.cwd(), ".data", "pglite"));
-const ran = await migrate(db);
-console.log(ran.length ? `migrations: ${ran.join(", ")}` : "migrations: nada pendente");
-await db.close();
+/**
+ * Aplica as migrations pendentes. `--dry-run` apenas lista: usado no pipeline
+ * antes do passo manual de migração, para que ninguém descubra o que vai rodar
+ * só depois de ter rodado.
+ */
+const dryRun = process.argv.includes("--dry-run");
+
+bootstrapScript("migrate");
+
+runWithDb("migrate", async (db) => {
+  const pending = await pendingMigrations(db);
+  console.log(`alvo: ${describeTarget()}`);
+  console.log(`shim de identidade: ${identityShimEnabled() ? "SERÁ aplicado" : "NÃO será aplicado"}`);
+  if (pending.length === 0) {
+    console.log("migrations: nada pendente");
+    return;
+  }
+  if (dryRun) {
+    console.log(`migrations pendentes (dry-run, nada aplicado): ${pending.join(", ")}`);
+    return;
+  }
+  const ran = await migrate(db);
+  console.log(ran.length ? `migrations aplicadas: ${ran.join(", ")}` : "migrations: nada pendente");
+});