🔁 CONTEXTO DO PROJETO (SaaS multi-tenant)

Stack:
- Supabase
- Multi-tenant por clinic/tenant
- Assinaturas por tenant (subscriptions.tenant_id)
- Controle de features: features, plan_features, subscription_intents, entitlementsStore, view v_tenant_entitlements
- Ativação manual: activate_subscription_from_intent()
- Merge concluído: agenda_online → online_scheduling.manage
- Entitlements e bloqueio PRO no menu funcionando
- Signup + intent funcionando; ativação cria subscription ativa; view retorna feature correta

Modelo de “Contas” decidido:
- Auth user (login) ≠ Clínica (tenant)
- Clínica = tenant; Usuário pode ser dono/admin de clínica e também profissional
- Clínica convida usuários (tenant_members). Usuário pode aceitar/recusar.
- Profissional pode trabalhar anos e depois sair: clínica mantém registros; profissional mantém histórico (audit trail), sem acesso após saída.

Regras de offboarding:
- Profissional só pode sair se NÃO houver agenda futura atribuída a ele.
- Se houver, cria “pedido de saída” e admin precisa realocar/cancelar; depois finaliza saída.

Tabelas existentes:
- tenant_members: (id uuid pk, tenant_id uuid, user_id uuid, role text, status text, created_at timestamptz)
  - UNIQUE (tenant_id, user_id) atualmente
- Agenda: agenda_eventos, agenda_excecoes, agenda_configuracoes, agenda_regras_semanais
- Outros: subscriptions, subscription_intents, plan_features, features, subscription_events

O que estamos fazendo agora:
- Ajustar modelo de membership lifecycle e offboarding (exit_requests)
- Garantir integridade: histórico de vínculos + auditoria + bloqueio de saída com agenda futura
- Implementar SQL + RPC + RLS + UI (passo a passo)

✔ subscriptions
Representa o plano da clínica (tenant)
✔ tenant_members
Define quais usuários pertencem à clínica
✔ entitlements

Define o que aquela clínica pode usar

Dados que faltam confirmar:
1) Estrutura de agenda_eventos (colunas e como relaciona com profissional)
2) Valores usados em tenant_members.status (active/invited/etc)
3) Estratégia de reentrada: remover UNIQUE (tenant_id,user_id) e usar unique parcial por status ativo/convite
4) Se existe tabela public.users como espelho do auth.users