Webhooks de canal não validam payload com Zod — divergência repo-wide da doutrina

[melgarafael]

O CLAUDE.md estabelece "Zod em todo input externo (request body, webhook payload, env)". O diretório lib/channels/ inteiro não usa Zod:

$ grep -rln 'from "zod"' lib/channels/
(vazio)
$ grep -rln 'from "zod"' lib/api/     # controle positivo: o grep está vivo
lib/api/client.ts

Os payloads de webhook são lidos por type-guards manuais (obj/str em lib/channels/zernio/webhook.ts:100-102, e equivalentes no canal meta). Funciona, mas cada campo novo depende de alguém lembrar de checar o tipo, e a divergência entre o que o parser aceita e o que o resto do código assume não tem nada que a acuse.

Achado na triagem do PR #228. Não é regressão dele — é ausência repo-wide nesta família, que o PR apenas herdou ao seguir o padrão do canal existente.

Escopo

Os três parsers de webhook de canal (waha, meta, zernio). O ganho real não é o Zod em si: é o payload passar a ter um schema declarado, em vez de a forma esperada estar espalhada em type-guards.

[melgarafael]

Procede — mas "repo-wide" está exagerado, e o número certo é mais acionável. Medido em origin/main f9abedd:

$ git ls-tree -r --name-only origin/main -- app/api/v1 | grep -c "route\.ts$"          -> 200
$ git grep -l "from \"zod\"" origin/main -- "app/api/v1/**/route.ts" | wc -l           ->  59
$ git grep -l "from \"zod\"" origin/main -- "app/api/v1/webhooks/**/route.ts" | wc -l  ->   0
$ git grep -l "from \"zod\"" origin/main -- "lib/channels/"                            -> (vazio)
$ git ls-tree -r --name-only origin/main -- lib/channels | wc -l                       ->  39

(controle positivo do grep: lib/api/client.ts aparece, então a sonda está viva)

Ou seja: a doutrina é seguida no resto da API e não é seguida em nenhum dos 9 webhooks. O rótulo certo não é "divergência repo-wide", é "a família de webhook inteira está fora" — o que é mais fácil de fechar e mais fácil de vigiar com um gate.

Contexto que aumenta a prioridade: o PR #241 consertou um ReDoS polinomial HIGH em lib/waha/ingest.ts cuja alcançabilidade dependia exatamente disto. O payload.from chega por JSON.parse(rawBody) as WahaEnvelope — cast, não validação — numa rota cujo WAHA_WEBHOOK_REQUIRE_SIGNATURE é false por padrão, e parseChatId roda antes de qualquer guarda. Sem Zod, todo campo do payload é unknown disfarçado de string: hoje um p.from não-string faz .endsWith lançar, o try/catch engole e a request devolve 200.

Nesta rodada eu consertei a instância (a regex) e não a classe (a validação ausente) — o que deixa a família com o mesmo álibi de sempre. Fica aqui registrado como o item que fecha a classe.