fix(auth): access token de 15min para 8h

Usuário pediu explicitamente pelo menos 8h. O TTL curto original era
deliberado (ADR-0003, reduzir janela de token vazado), mas o frontend
nunca implementou refresh silencioso — na prática o usuário era
derrubado no meio do trabalho sem nenhuma renovação automática. 8h é
um paliativo real, documentado como tal num adendo na própria ADR-0003
(com a mitigação que já existe — revogação de sessão continua granular
— e o que resolveria isso de verdade sem abrir mão de segurança:
refresh silencioso no frontend).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

docs/progress.md

@@ -731,3 +731,34 @@ Data: 2026-09-18. Usuário pediu: "primeiro vem os dados PJ depois vem os sócio
 
 ### Verificação
 `pnpm turbo run typecheck build` 28/28. Suíte 100/100 (inalterada — mudança é só de frontend). Testado ao vivo em navegador real via Playwright: ordem das seções confirmada por leitura do DOM (`Status, Dados PJ, Sócios, Endereço, Contatos`) e por screenshot; ciclo completo com CNPJ real (Petrobras) mostrando os 10 sócios na nova posição; salvamento testado preenchendo um campo de cada `<form>` e confirmando após reload que os dois persistiram. Cadastro de teste desativado ao final.
+
+---
+
+## Access token: 15min → 8h
+
+Data: 2026-09-18. Usuário pediu diretamente: "ajuste o tempo de acesso do token preciso que seja no mínimo 8 horas". Implementado diretamente (mudança pequena, uma constante).
+
+`ACCESS_TOKEN_TTL_SECONDS` em `apps/api/src/auth/token.service.ts`: `15 * 60` → `8 * 60 * 60`. Achado ao investigar antes de mudar: o TTL curto original era uma decisão deliberada e documentada (ADR-0003, motivada pelo Master Prompt §5.3 — reduzir a janela de uso de um token vazado), mas o frontend nunca implementou refresh silencioso (`AuthContext.tsx`/`session.ts` documentam isso explicitamente: "No refresh-token rotation in this leva") — na prática, 15min derrubava o usuário no meio do trabalho, sem nenhum mecanismo automático de renovação. 8h é um paliativo real pro problema real, não só "afrouxar por afrouxar": documentado como tal num adendo na própria ADR-0003, com a mitigação que já existe (revogação de sessão continua granular, não depende do TTL do JWT) e o trabalho futuro real que resolveria isso sem abrir mão de segurança (refresh silencioso no frontend).
+
+### Verificação
+`pnpm turbo run typecheck build` 28/28. Suíte completa 106/106 (após a leva de Revenda abaixo, rodada em conjunto). Testado ao vivo: login real devolve `expiresIn: 28800` (exatamente 8h).
+
+---
+
+## Cadastro de Revenda — mesma expansão do Cadastro de Cliente (CNPJ, campos, reordenação)
+
+Data: 2026-09-18. Usuário pediu pra aplicar em Revenda a mesma coisa feita em Cliente: "fazer a busca automática de cnpj e expandir campos de cadastro e reordenar os campos". A tabela `resellers` até agora era minimalista (`name`/`document`/`contact_email`/`active`, sem endereço, sem sócios, sem os campos PJ que `client_registrations` já tinha).
+
+### Backend (agente `eden-commercial`)
+
+Migration `packages/database/migrations/1789700000000_resellers-expansion.cjs`: `resellers` ganha `trade_name`, `state_registration`, `municipal_registration`, `opening_date`, `legal_nature`, `cnpj_situation`, `main_activity`, `address_*`, `contact_principal/financial/technical_*` — mesmo shape de `client_registrations`, sem o prefixo `pj_` (não existe ambiguidade PF/PJ aqui — decisão deliberada: revenda não ganhou um `person_type`, é sempre tratada como PJ). Tabela nova `reseller_partners`, mesmo shape de `client_registration_partners`.
+
+Endpoints novos em `resellers.controller.ts`: `GET/POST /v1/resellers/:id/partners`, `PATCH /v1/resellers/:id/partners/:partnerId`, e `POST /v1/resellers/:id/cnpj-lookup` — **reaproveitando o adapter `lookupCnpj` já existente** (`@eden/integrations`, construído pra Cliente), mesma mecânica exata (servidor sempre reconsulta a fonte autoritativa, `COALESCE` em tudo que a API pode não trazer, dedup de sócios por `document`, `source: 'cnpj_lookup'`).
+
+**Decisão deliberada, diferente de Cliente**: `document` continua livremente editável via `PATCH` genérico — ao contrário de `pj_cnpj` em `client_registrations` (que é bloqueado de propósito, só a ação dedicada de lookup grava). Aqui a busca de CNPJ é só uma conveniência adicional, não uma trava nova.
+
+### Verificação
+`pnpm db:migrate`/`down`/`migrate` de novo — limpo. `pnpm turbo run typecheck build` 28/28. Suíte 106/106 (100→106, 6 testes novos). Testado ao vivo contra CNPJ real (Petrobras): nome/nome fantasia/inscrição estadual/endereço/10 sócios corretos, reexecução sem duplicar, `PATCH` manual em `document` confirmado ainda funcionando depois do lookup.
+
+### Pendências
+UI ainda não construída — só o backend nesta leva (frontend é o próximo passo natural, mesmo padrão de Cliente: Dados PJ → Sócios → Endereço → Contatos, já direto na ordem certa desta vez, sem precisar de uma segunda leva de reordenação).