———————————————————————————————————————————————————————————————————————————==
P5.4 — o realm de um tenant novo.

DERIVADO de `tenants/plataforma/realm/athleticmap-realm.json`, que e o realm
que existe hoje. Os nove papeis e o cliente `spa` sao os de la — NAO inventei
nenhum, e um papel a mais aqui seria um papel que nenhum codigo verifica.

── OS MARCADORES ───────────────────────────────────────────────────────────

  {{REALM}}   `athleticmap-<N>` — decidido em 2026-09-19
  {{TENANT}}  o nome comercial, que vira o subdominio

SAO COISAS DIFERENTES desde aquela decisao. O realm e numerado porque uma
instancia so de Keycloak nao comporta quatro realms chamados `athleticmap`; o
subdominio e o nome que o cliente ve.

── O DOMINIO DOS REDIRECTS ─────────────────────────────────────────────────

`athleticmap.com`, e nao `athleticmap.influxdigital.com.br` — o canonico foi
decidido em 2026-09-16 (P0.9). O tenant `plataforma` ainda usa o antigo porque
o corte de dominio nao aconteceu; um tenant NOVO ja nasce no certo.

Se o corte nao tiver acontecido quando o primeiro tenant for provisionado, ESTE
arquivo precisa mudar junto — e o sintoma de esquecer e um login que redireciona
para um host que nao resolve.

── NAO HA USUARIO AQUI ─────────────────────────────────────────────────────

O administrador do cliente e criado pela Admin API, DEPOIS do realm, porque ele
precisa de senha temporaria e de `UPDATE_PASSWORD` — e nenhum dos dois cabe num
arquivo versionado. Ver EtapaCriarRealm.
———————————————————————————————————————————————————————————————————————————==


— O SMTP, E POR QUE ELE VIVE AQUI ————————————————————————————————————

Quem manda o e-mail de boas-vindas e o PROPRIO KEYCLOAK, pela Admin API
(`execute-actions-email`), e nao o `servico-captacao`.

Isso tem tres consequencias boas:

  1. o nosso servico nao precisa de biblioteca de e-mail nem de configuracao de
     SMTP — uma dependencia a menos e um segredo a menos por onde vazar;
  2. o link de definicao de senha e gerado e assinado pelo proprio Keycloak, com
     validade propria. Nao ha token nosso a inventar, guardar nem expirar;
  3. "fechar a aba e voltar depois pelo link do e-mail" — criterio do card —
     funciona de graca, porque o link nao depende de sessao nenhuma.

A SENHA DO SMTP NAO FICA NESTE ARQUIVO. Os marcadores sao preenchidos em memoria,
no momento de criar o realm, a partir da configuracao do servico — o realm e
criado pela API, e nao commitado. Um `{{SMTP_SENHA}}` literal que chegasse ao
Gitea seria um segredo versionado, que e exatamente o que a regra do repositorio
proibe.

── O `frontendUrl`, E POR QUE ELE NAO E OPCIONAL ───────────────────────────

`https://auth.athleticmap.com` — o host de autenticacao DOS TENANTS.

Sem ele o Keycloak monta os links (e o `iss` do token) com o `KC_HOSTNAME`
global, que e `auth-plataforma.athleticmap.com`. E os runtimes do tenant
validam contra `ATM_ISSUER`, que o molde consolidado define como
`https://auth.athleticmap.com/realms/{{REALM}}`.

Os dois TEM de bater. Quando nao batiam, em 2026-09-24, o login do primeiro
tenant provisionado morria antes de comecar: a SPA redirecionava para um host
sem certificado e sem rota, e mesmo passando por cima o token seria recusado
pelos runtimes.

Nao da para resolver so no `KC_HOSTNAME` porque ele e um so, e a plataforma
depende do valor antigo — os servicos dela estao configurados com
`auth-plataforma`. Dai o `frontendUrl` por realm, que e exatamente para isto.