Intermittent PostgreSQL deadlock while changing memory recall preferences #1396

The chat PostgreSQL runtime check intermittently deadlocks while changing memory recall preferences. Keep this tracked separately from the Sentry filtering fix in #1327.

AI review notes: CI run https://github.com/TanStack/tanstack.com/actions/runs/39036737723/attempts/1 failed in harness-tests/pending-runtime/memory-runtime.test.ts, case recall enabled=false controls tools in the actual assistant loop. Memories.setPreferences reached Memories.authorize at src/chat/server/memory.ts:64 and PostgreSQL returned 40P01 while locking chat_conversations. The query uses FOR UPDATE OF chat_bots, chat_conversations, chat_memberships; the test changes preferences after h.c.begin returns, while background publication may still be running.

The same commit, b092eedc05c28a346a5d44e6ee23c3c7cfbc6a9f, passed a single diagnostic CI rerun. An isolated local PostgreSQL 17 database also passed the memory file's 9 tests and the full runtime suite's 278 tests across 35 files. These passes do not establish the cause or prove the deadlock harmless. No database code changed in #1327.

Next: capture both transactions from PostgreSQL's deadlock log, reproduce their lock ordering deterministically, and test the correction without weakening authorization or hiding failures with blanket retries. Interaction with the activity outbox's foreign-key locks is a hypothesis, not a confirmed diagnosis.