Retorna o catálogo de IDs numéricos que o backend Autra exige nos payloads
de cadastro PF/PJ. A Autra não aceita strings ("MALE", "MARRIED",
"RESIDENTIAL"); espera IDs (gender_id: 3, marital_status_id: 1,
address.type_id: 12). Os IDs mudam por ambiente (sandbox ≠ produção)
e podem ser atualizados pela Autra — por isso é catálogo dinâmico, não enum
hardcoded no frontend.

Quando usar

Sempre que renderizar formulário de:

• Cadastro PF — gender_id, marital_status_id, telefone, email, endereço, documento
• Cadastro de sócio (PJ) — todos os campos acima por sócio
• Cadastro da empresa (PJ) — endereço, telefone, email da empresa

Fluxo típico no frontend:

1. Ao abrir tela de cadastro → GET /v1/banking/onboarding/setup-types
2. Backend devolve as 6 categorias (cacheadas — <50ms)
3. Renderiza dropdowns: <option value={id}>{description}</option>
4. Ao submeter, manda os id selecionados nos campos do payload

Categorias disponíveis

Filtro opcional

• Sem filtro (GET /setup-types) → retorna todas as 6 categorias de uma vez (recomendado: 1 round-trip pra montar todo o form)
• Com ?category=GENDER → retorna só essa categoria (útil pra hot-reload de um campo específico)

Cache

• Cacheado em memória do Lambda após o primeiro LoadAll (cold start dispara em goroutine, ~200ms paralelo).
• Subsequentes chamadas servem do cache (<50ms).
• Cache invalida apenas em cold start (deploy ou ociosidade > 15min).
• Para forçar refresh: re-deploy do banking lambda.

Auth

Cognito (master logado do tenant). Não é público.

Mapeamento com payloads PJ

Veja referências no schema:

• OnbPersonalDataRequest.gender_id ← category=GENDER
• OnbPersonalDataRequest.marital_status_id ← category=MARITAL_STATUS
• OnbAddress.type_id ← category=ADDRESS
• OnbPhone.type_id ← category=PHONE
• OnbDocument.type_id ← category=DOCUMENT (no upload de arquivos)
• email.type_id (não está em schema dedicado mas obrigatório no payload PJ) ← category=EMAIL