[FEAT] Autenticação do CLI para execução em CI

[cpenaforte-clickbus]

User story

Como o worker rodando em CI, eu quero autenticar no /api/ingest sem login interativo, para que o
--push funcione num runner onde ninguém digita iris login.

O problema

O --push assume login interativo: get_auth() lê ~/.iris/config.json, escrito pelo iris login.
Num runner esse arquivo não existe.

A decisão — duas saídas, e esta issue escolhe

O DD deixa a escolha explicitamente para a Fase 1:

Saída A — o workflow escreve o arquivo a partir de secrets. Funciona hoje, zero código. Em
troca, o token passa pelo disco do runner e a forma do arquivo vira contrato implícito do CI.

Saída B — get_auth() ganha fallback para IRIS_TOKEN / IRIS_SERVER_URL. Três linhas, e é o que
um worker centralizado quer. IRIS_SERVER_URL já é lido hoje em iris/platform/auth.py:14
(DEFAULT_SERVER), então na prática só o token é novo.

Acceptance criteria

• Decisão registrada com o motivo, na issue e em docs/DECISIONS.md
• Implementada a saída escolhida
• O caminho interativo continua funcionando sem alteração — iris login e ~/.iris/config.json
  seguem sendo o padrão para a máquina do desenvolvedor
• Teste cobrindo: sem config e sem env → erro claro; com env → autentica; com config → autentica

Scope / non-goals

Fora: rotação dos secrets, que é definida junto do pedido do GitHub App, e as flags do worker, que
são da Fase 2.

Se encaixa em qual estágio?

Stage 2 — Ingestion: reliability of CLI → /api/ingest pipeline, token auth.

Links

• DD 0010 §5 — "Duas saídas, e a escolha é da Fase 1": https://github.com/RocketBus/clickbus-rfc-design-docs/blob/main/design-docs/DD0010-Coleta-Centralizada-de-Atribuicao-do-Iris.md
• Parte de: Fase 1 — Watermark e ingestão idempotente #209