ci: consertar o pipeline de deploy e subir as functions para Node 22

[vitorrgg]

Resolve a #177: o pipeline reportava sucesso sem publicar, e o runtime declarado não é mais aceito pelo Cloud Functions. Este PR corrige os dois.

1. O deploy não falhava quando falhava

O workflow chamava a API programática do firebase-tools (client.functions.config.set() + client.deploy()) via scripts/firebase-deploy.js. Esse caminho encerrava o processo Node com exit 0 sem deployar: o step durava 3 segundos, não emitia nenhuma linha do firebase deploy e não chegava nem no .then nem no .catch do script — e o Actions marcava verde. Todo merge em master desde 25/07/2025 ficou fora do ar com o CI verde.

Mudanças:

• Deploy pelo CLI (npx firebase-tools@13 deploy --only functions --non-interactive), que retorna exit code ≠ 0 quando falha.
• Verificação pós-deploy: compara o updateTime da function antes e depois e falha o job se não avançou. É a rede que impede a reincidência mesmo que algum caminho novo volte a falhar em silêncio.
• Suporte a service account (FIREBASE_SERVICE_ACCOUNT), com fallback para o FIREBASE_TOKEN atual emitindo ::warning::. O firebase login:ci foi descontinuado pelo Google; o fallback mantém o comportamento de hoje, agora falhando alto se o token estiver morto.
• workflow_dispatch com input dry_run, para validar sem publicar. Hoje só dá para deployar via push no master, o que torna qualquer teste de pipeline um evento de produção.
• scripts/firebase-deploy.js reduzido a gerar o functions/.env. O functions.config.set() foi removido: a API foi descontinuada pelo Google e o runtime config do projeto está com todos os valores vazios — as functions já leem tudo de variável de ambiente (functions/__env.js cai no fallback process.env). Era código morto. O script agora também falha se SERVER_OPERATOR_TOKEN estiver vazio, em vez de escrever um .env incompleto: sem esse valor, functions/index.js rejeita todo webhook recebido.
• Removido o predeploy npm --prefix "$RESOURCE_DIR" run do firebase.json — sem nome de script, só listava os scripts e saía.
• Actions v3 → v4, Node do runner → 22, ::set-output (já descontinuado) → $GITHUB_OUTPUT.

2. O runtime declarado não existe mais

functions/package.json pedia Node 18, que o Cloud Functions não aceita mais. Consultando a API do projeto, os runtimes disponíveis hoje são:

runtime	estágio	descomissionamento
nodejs18	não consta	já descomissionado
nodejs20	DEPRECATED	30/10/2026
nodejs22	GA	30/10/2027
nodejs24	GA (só gen2)	31/10/2028

Sem esse bump, nenhum deploy pode dar certo — nem com o pipeline consertado. Subimos direto para 22, porque o 20 já está deprecated com descomissionamento em três meses.

Verificação feita antes do bump: instalei as dependências de functions/ do master com Node 22 e carreguei os módulos críticos. Todos carregam sem erro:

OK  firebase-admin            (v10)
OK  firebase-functions        (v4)
OK  @ecomplus/application-sdk v22.0.0-firestore.1.15.7
OK  @ecomplus/client          v2.4.0
OK  axios                     v0.27.2
OK  firebase-functions/v2/https
    admin.firestore existe: true

Ou seja, o bump não arrasta upgrade de SDK. Também confirmei que o firebase-tools@13.35.1 sabe declarar nodejs22.

⚠️ Sobre rollback — importante

Reverter este PR inteiro não é rollback. Se algo der errado depois do deploy, reverter o engines.node para 18 deixa o repo indeployável de novo: você fica com a versão nova no ar e sem conseguir publicar nada por cima.

O rollback real, se precisar, é reverter só o código do app, mantendo o Node 22:

git revert 413b1aa   # o guard de variação, único código de app que ainda não rodou em produção
# NÃO reverter functions/package.json nem .nvmrc

Isso publica o código que está em produção hoje sobre um runtime que o Google aceita — que é a única rede de segurança possível, e que este PR cria.

O que esperar no primeiro deploy

O primeiro deploy bem-sucedido publica duas mudanças de uma vez: o runtime novo e o guard de variação do 413b1aa, que nunca rodou em produção. Vale acompanhar em janela de baixo movimento, olhando:

• GET https://us-central1-<projeto>.cloudfunctions.net/app/ devolvendo o application.json
• webhooks do Tiny voltando a logar > Tiny webhook: #loja
• x-operator-token sendo aceito — é o que barra 100% dos webhooks se o .env sair errado
• exportação de pedido funcionando
• e o sinal de que o bug da fix: use webhook variation data as fallback for importation queue #174 foi resolvido: POST /products/<pai>/variations.json aparecendo no log, hoje com zero ocorrências

Antes de mergear, dá para validar com Actions → Deploy → Run workflow e dry_run marcado — valida credencial, empacotamento e runtime sem publicar nada.

Pendência (fora deste PR)

• Criar service account no projeto e adicionar o secret FIREBASE_SERVICE_ACCOUNT. Sem ele, o step de verificação é pulado e a autenticação segue no token descontinuado. Papéis mínimos: Cloud Functions Admin, Service Account User, Cloud Build Editor, Storage Admin.

Closes #177