Web server: autenticação (bloqueador de deploy)

[afonsof]

Follow-up do MVP do servidor web (peça 1/2 do porte web — ver docs/superpowers/specs/2026-07-27-ldtk-web-port-design.md). O MVP foi entregue sem autenticação por decisão de escopo. Antes de qualquer deploy não-local:

• Autenticação — hoje qualquer um com acesso à rede lê/escreve qualquer projectId. Definir estratégia (token do produto hospedeiro, validado no servidor) conforme o design.
• CORS — server/src/app.ts usa cors() aberto a todas as origens. Restringir às origens do produto hospedeiro.
• Echo de input em erro 400 — server/src/errors.ts / server/src/routes/validate.ts refletem o valor rejeitado na mensagem. Não é vetor (nada é lido/escrito), mas evitar ecoar payload do cliente.

Contexto: path traversal via params já foi corrigido (commit d962e98a). Isto é o restante da superfície de segurança.

[afonsof]

Parcialmente concluído — os dois itens de rede foram feitos; autenticação segue adiada por decisão de escopo, e é só por isso que esta issue continua aberta.

Feito

• Bind em loopback por padrão (BIND_HOST, default 127.0.0.1). Antes o servidor escutava em 0.0.0.0 silenciosamente — bastava rodar numa máquina com IP público para ficar aberto. Expor agora é ato explícito e imprime um aviso destacado no log sobre a ausência de autenticação.
• CORS por lista de origens (CORS_ORIGINS, separadas por vírgula; sem a env libera só localhost em qualquer porta). Requisições sem Origin seguem passando — CORS é política de navegador e bloqueá-las daria falsa sensação de segurança sem impedir um curl.
• Erros não ecoam mais o input: Invalid id: ../../secret virou Invalid id: expected letters, digits, hyphen or underscore.

19 testes novos (57 no total no servidor); o e2e passa com os novos defaults, confirmando que o fluxo real não quebrou.

O que falta — e por que importa

Sem autenticação este servidor não pode ser exposto publicamente. Não há controle de acesso algum: quem alcança a porta lê, modifica e apaga qualquer projeto, e o projectId não é segredo (demo, test e afins são adivinháveis). Até haver auth, rode só em localhost ou atrás de um proxy que autentique.

Quando for implementar, as opções discutidas foram: JWT assinado pelo produto hospedeiro (sem estado no servidor), token opaco validado por callback (revogável na hora, mas acopla os serviços), ou chave de API estática (trivial, não distingue usuário nem projeto).

Spec: docs/superpowers/specs/2026-07-27-server-network-hardening-design.md