docs: gotcha pgrst.db_schemas nao sobrevive ao restart do stack

Apos supabase stop/start a GUC de exposicao dos schemas tenant some -> 404 nas
tabelas tenant. HANDOFF Passo 0 agora manda rodar refresh_pgrst_schemas() pos-start.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

docs/HANDOFF_E_TESTES.md

@@ -93,11 +93,20 @@ Está no estado **schema-per-tenant + freemium aplicado**:
 ### Passo 0 — Ativar a confirmação de e-mail
 A confirmação só vale após reiniciar o stack (o volume do banco **persiste** — nada se perde):
 ```bash
-supabase stop && supabase start      # ou o tooling equivalente do projeto
+supabase stop && supabase start      # se falhar com containers unhealthy, rode start de novo (transiente)
 ```
 Conferir no Studio/Mailpit que está de pé. (Se preferir NÃO testar confirmação agora, pule —
 o front trata os dois casos; mas o fluxo "confirme e-mail" só aparece com isto ligado.)
 
+> 🔴 **GOTCHA OBRIGATÓRIO pós-restart** — a GUC `pgrst.db_schemas` (exposição dos schemas
+> tenant no PostgREST) **NÃO sobrevive ao `supabase stop/start`** (o `start` reseta a role
+> `authenticator`). Sem isso o app dá **404** em todas as tabelas tenant. Rodar SEMPRE após start:
+> ```bash
+> docker exec -i supabase_db_agenciapsi-primesakai psql -U supabase_admin -h 127.0.0.1 -d postgres \
+>   -c "select public.refresh_pgrst_schemas();"
+> ```
+> (Confirma exposição: `curl -s -o /dev/null -w "%{http_code}" "http://127.0.0.1:64321/rest/v1/patients?limit=1" -H "Accept-Profile: tenant_<slug>"` deve dar 200.)
+
 ### Passo 1 — Schema-per-tenant: tenants EXISTENTES ainda funcionam
 1. `npm run dev`, logar num tenant existente (ex.: clínica Bem-Estar / um terapeuta).
 2. Abrir **Agenda, Pacientes, Financeiro, Conversas** → tudo carrega (lendo de `tenant_<slug>`).