feat(database): migration de seed com os 7 templates reais de documento

Traz pro código os 7 templates importados na leva anterior (Contrato de
Software, Termo de Cessão, Termo de Portabilidade, Termo de Contratação
STFC, Contrato Canal Finder, Contrato Canal Recorrente, Termo de Adesão) —
uma VM nova já nasce com eles publicados assim que roda `pnpm db:migrate`,
sem precisar reimportar manualmente. Segue o mesmo padrão de seed já usado
neste repo pra dado de catálogo (INSERT ... ON CONFLICT DO NOTHING dentro
da própria migration), idempotente por key.

Corrige de passagem um html_content vazio em 4 dos 7 JSONs originais
(não afeta geração/editor, só o card de preview) — recalculado com o
próprio renderToHtml antes de virar seed.

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

docs/progress.md

@@ -971,3 +971,40 @@ anteriores desta sessão — desativados via `UPDATE document_templates SET acti
 usado antes). Restaram ~9 templates de teste manual mais antigos (`client_test_contract`, `live_test_*`,
 `smoke_*`, `teste_web_final` etc.) que não seguem o prefixo `qa_test_` automatizado — não mexidos, por
 poderem ser exploração manual do próprio usuário.
+
+---
+
+## Os 7 templates viram parte do código (migration de seed)
+
+Data: 2026-09-19. Usuário pediu pra embutir os 7 templates importados na leva anterior no próprio código,
+pra que uma máquina nova (VM de pré-produção) já nasça com eles, sem precisar rodar o script de importação
+manualmente de novo.
+
+Padrão já usado neste repo pra dado de catálogo/referência é seed **dentro de uma migration** (`INSERT ...
+ON CONFLICT DO NOTHING`, ver `1788457368744_fiscal.cjs`/`fiscal_operation_nature` e
+`1788430575858_baseline-schema.cjs`/`applications`/`roles`) — não um serviço à parte. Nova migration
+`packages/database/migrations/1789862600000_seed-document-templates.cjs` segue o mesmo padrão, com os 7
+JSONs (key/name/doc_group/editor_content/html_content/css_content) copiados em
+`document-template-seeds/*.json` ao lado dela. Idempotente por `key`: nunca sobrescreve um template já
+existente (ex.: se alguém já editou manualmente).
+
+Único `up`/`down` assíncrono desta pasta de migrations (as outras usam `pgm.sql` síncrono) — precisa do
+`id` gerado pelo INSERT do template antes de inserir a versão, e do `id` da versão antes de apontar
+`current_version_id` de volta, então usa `pgm.db.query` parametrizado em vez de `pgm.sql`.
+
+**Achado real, corrigido no caminho**: o `html_content` do export original vinha **vazio** pra 4 dos 7
+templates (`client_cession_term`/`client_portability_term`/`client_software_contract`/`client_stfc_term`)
+— só os 3 `reseller_*` tinham. Não afeta geração real nem o editor (ambos leem `editor_content` direto),
+só deixaria o card "Preview da versão publicada" vazio pra esses 4 numa instalação nova. Corrigido
+recalculando o `html_content` desses 4 offline com o próprio `renderToHtml` (o mesmo já testado nesta
+sessão, via `apps/api/dist/documents/editor-content-renderer.js` compilado) antes de gravar os JSONs de
+seed — não precisou mudar nada no motor em si.
+
+### Verificação
+Testado contra banco **totalmente vazio** (não só o de desenvolvimento, que já tinha os 7 da importação
+manual anterior): criado `eden_migration_test` no mesmo Postgres, rodado `node-pg-migrate up` do zero
+(todas as migrations, não só esta) — os 7 templates nasceram publicados, com `editor_content` e
+`html_content` corretos (conferido via query direta: `jsonb_array_length`/`length(html_content)` > 0 para
+os 7). Banco de teste apagado depois. `pnpm --filter @eden/database typecheck` e suíte da API
+125/125 sem regressão. Runbook (`docs/runbooks/setup-vm-pre-producao.md`) atualizado avisando que o passo
+de migrations já traz os templates.