docs: registra troca da memória da sessão para Postgres (Z-PRO)

Nova seção 16: node Memória da Sessão (RAM) trocado pelo Postgres
Chat Memory oficial, tabela n8n_chat_histories criada
automaticamente. Container Postgres com um banco por cliente,
credencial por workflow. Testado de ponta a ponta em produção: duas
mensagens em sequência confirmam que o contexto persiste entre
execuções separadas do workflow.

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

docs/n8n-agendamento-runbook.md

@@ -508,3 +508,54 @@ já externalizada para o Google Doc de teste
 real de produção da clínica exemplo quando o gestor tiver o conteúdo
 definitivo. Padrão pronto pra replicar em Klingo/SysLife/ClinicAll
 quando esses tiverem workflow de agente.
+
+## 16. Memória da sessão via Postgres (substitui o buffer em RAM, só Z-PRO)
+
+**Data:** 11/08/2026. Ver design completo em
+`docs/superpowers/specs/2026-08-11-memoria-sessao-postgres-design.md` e
+plano em `docs/superpowers/plans/2026-08-11-memoria-sessao-postgres.md`.
+
+**Motivação**: o node `Memória da Sessão` (`memoryBufferWindow`/"Simple
+Memory") guardava o histórico da conversa só em RAM do processo do
+n8n — não sobrevive a um reinício (deploy, crash, atualização) e não
+funcionaria em setups com múltiplos workers (queue mode). Trocado pelo
+node oficial `Postgres Chat Memory`, que persiste o histórico num banco.
+
+**Infraestrutura**: o usuário provisionou um **container Postgres**, com
+**um banco por cliente/clínica** dentro dele (mesma filosofia de
+isolamento já usada pra `docId`, `baseUrl`/`apiId` dos MCP Servers).
+Credencial no n8n: `Postgres Agendamento - (clínica exemplo)`
+(`xq3QAN3MZSOCVgdY`), apontando pro banco do Z-PRO. Cada cliente futuro
+terá sua própria credencial, apontando pro banco dele no mesmo
+container.
+
+**Troca implementada** (operação atômica — adicionar + conectar +
+remover, mesma lição da seção 15 sobre nós desconectados): saiu
+`Memória da Sessão` (`memoryBufferWindow`), entrou `Memória da Sessão
+(Postgres)` (`@n8n/n8n-nodes-langchain.memoryPostgresChat`, v1.4), com
+os mesmos parâmetros de sessão de sempre (`sessionKey: ={{
+$json.sessionId }}`, `contextWindowLength: 20`). A tabela
+`n8n_chat_histories` foi criada **automaticamente pelo node** na
+primeira execução — sem setup manual de schema.
+
+**Sem migração de histórico**: o histórico anterior só existia em RAM,
+não havia nada a migrar — mesmo efeito que já acontecia a cada reinício
+do n8n, só que agora deixa de acontecer daqui pra frente.
+
+**Teste real de validação (11/08/2026)**: duas mensagens enviadas em
+sequência ao webhook de produção, mesmo `protocol`
+(`teste-memoria-postgres-01`) — primeira mensagem informando um nome
+fictício, segunda perguntando "qual nome você anotou". O agente
+respondeu corretamente com o nome da primeira mensagem, confirmando que
+o contexto persistiu **entre duas execuções separadas do workflow**
+(prova de que não é mais RAM do processo, já que cada chamada webhook é
+uma execução isolada). Confirmação direta via `SELECT` na tabela
+`n8n_chat_histories` não foi feita (sem necessidade de dar acesso ao
+banco pra automação — a prova conversacional já foi considerada
+suficiente).
+
+**Resultado**: workflow ativo em produção com memória de sessão
+persistida em Postgres. Padrão pronto pra replicar em
+Klingo/SysLife/ClinicAll quando esses tiverem workflow de agente — cada
+um com seu próprio banco dentro do mesmo container e sua própria
+credencial.