wiki: F6.2 Lote C done

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

Obsidian/Brain/log.md

@@ -1663,3 +1663,6 @@ Touched: Migracao Schema-per-Tenant
 
 ## [2026-06-13 13:34] session | F6.2 Lote A+B triggers (agnosticos + schema-aware)
 Touched: Migracao Schema-per-Tenant
+
+## [2026-06-13 14:10] session | F6.2 Lote C split notifications
+Touched: Migracao Schema-per-Tenant

Obsidian/Brain/wiki/Migracao Schema-per-Tenant.md

@@ -20,7 +20,7 @@ Sub-lotes propostos (cada um com smoke test + commit):
 - **A** ✅ DONE (commit d58b939, migration 20260613000004): `attach_agnostic_triggers(schema)` recria os triggers agnósticos (8 setters updated_at + 2 prevent_*) nos 9 schemas (54 triggers/schema). Smoke: set_updated_at dispara. Wiring no clone fica pro fim da F6.2.
 - **B** ✅ DONE (commit 5741e10, manual/f6_2b_schema_aware_triggers.supabase_admin.sql — roda como supabase_admin pois trigger fns são owned por supabase_admin). 14 funcs reescritas (set_config search_path dinâmico + tenant_id_for_schema p/ audit_logs global); sync_busy_mirror cross-tenant via tenant_schema_for+EXECUTE format; financial_records_inject_tenant obsoleto (não anexado). Detach dos 14 de public + attach 22 triggers/schema (defs reais, tenant_id removido de WHEN/UPDATE OF). Smoke: sessão→realizado cria financial_record no schema + audit roteia tenant_id certo + timeline OK.
   - **Gotchas Lote B**: (1) trigger functions owned por supabase_admin → CREATE OR REPLACE só como supabase_admin (vira manual, não db.cjs). (2) Triggers reais tinham `WHEN (new.tenant_id=new.owner_id)` e `UPDATE OF tenant_id,...` → quebram no schema; remover tenant_id dos WHEN/colunas ao re-anexar. (3) Estratégia hybrid: detach de public pra função reescrita não rodar errada lá.
-- **C** split notifications: `public.notifications_sistema` (tipos cross-tenant: avisos SaaS, suporte, system_alert) + `tenant_<x>.notifications` (locais); refatorar notify_user/notify_tenant_admins/notify_all_devs/mark/archive (2 variantes); migrar dados por type; `useNotifications.js` lê 2 fontes (campo `_origem`), realtime 2 canais; ALTER PUBLICATION add notifications_sistema.
+- **C** ✅ DONE (commit bedbb9b, manual/f6_2c_notifications_split.supabase_admin.sql). DESCOBERTA: neste projeto TODAS as notifs atuais (inbound_message, session_status, system_alert, new_patient) são tenant-LOCAIS — avisos cross-tenant do SaaS vivem em `global_notices`, não em notifications. Então: notifications fica tenant-local (já nos schemas); `public.notifications_sistema` criado como canal SaaS→tenant FUTURO (vazio hoje) + RLS + realtime + notify_user_sistema(). 4 notif-triggers tenant reescritos schema-aware + detach public + attach (5/schema); notify_on_intake/scheduling disparam em tabelas PUBLIC (F1b) → roteiam pro schema via tenant_schema_for+EXECUTE format; cancel_patient_pending herda search_path do chamador. Smoke: msg inbound → notif no schema, destinatário certo. Frontend notificationStore.js: load 2 fontes + merge por created_at + `_origem`; realtime 2 canais; markRead/archive roteiam por _origem. conversation_messages.id é bigint (gotcha no teste).
 - **D** RPCs de usuário (~30: mark_as_paid, create_financial_record_for_session, safe_delete_patient, search_global, cancel_recurrence_from, export_patient_data…) → `p_tenant_id` validado com `is_tenant_member` + `set_config(search_path)`.
 - **E** RPCs global/cron (~10: populate/cleanup/unstick_notification_queue, sync_overdue_financial_records, whatsapp_heartbeat_*, sla_*) → loop `FROM tenants`.
 - **F** RPCs anon/token (~8: get_patient_intake_invite_info, sign_document_by_token, validate_share_token, agendador_*) → leem tabelas anon (public, F1b) e roteiam writes de tabela tenant (ex. document_signatures) pro schema via tenant resolvido do token.