migrate: preservar Secret blocks criptografados (não inline plaintext) + doc browser-key vs server-secret

Observação (portal-davinci run, 2026-08-20)

Contexto

A Google Maps apiKey está em plaintext no decofile migrado (AIzaSy...). Verifiquei: o original portal-davinci já estava plaintext — então não é regressão, é dívida herdada copiada fielmente.

Dois pontos pro plugin

1. Migrate deve preservar Secret blocks como Secret (não decriptar pra plaintext)
Se um site original usa Secret blocks (valor criptografado, decriptado server-side via deco decrypt key), a migração NÃO pode decriptar pra plaintext no decofile de destino — seria regressão de segurança. Validar que deco-migrate preserva __resolveType de Secret e o ciphertext.

2. Distinguir browser-key de server-secret na doc/triager

• Server-only (VTEX token, API secret): deve ser Secret — decriptado server-side, nunca no client.
• Browser key (Google Maps): inerentemente pública (vai pro client no key: do script). Secret protege o decofile mas não esconde do usuário — a proteção real é HTTP referrer restriction. O triager podia sugerir: 'apiKey em plaintext no decofile → mover pra Secret; se for browser-key, garantir referrer restriction no provider'.

Runtime na CF

Secret blocks precisam da decrypt key no env/secret da CF Worker pra decriptar em runtime. Se não estiver setada → Secret vira vazio → seção quebra. O template-bootstrap deveria checar isso.

Transferida de decocms/parity#250 (bug de template do deco-migrate / @decocms/blocks-cli, fora do escopo do repo parity).

Start with deco-migrate and @decocms/blocks-cli, especially the migration path for Secret blocks and the template-bootstrap runtime setup. Check how __resolveType and ciphertext are handled, then review the CF Worker decrypt-key requirement and the browser-key versus server-secret documentation. Done means encrypted Secret blocks remain encrypted, runtime configuration is validated, and the guidance distinguishes public browser keys from server-only secrets.