knowledge: a Postgres outage now makes the knowledge base read-only — decide whether that is the intended degradation #15741

Summary

Since #15663 (PR #15668, 324fde1a), a knowledge fact is written to Postgres before its Redis projection, and that write is deliberately allowed to raise:

# autobot-backend/knowledge/facts.py:771-772
await fact_store.persist_fact(fact_id, content, metadata)
await self._project_fact_to_redis(fact_id, content, metadata)

store_fact's outer handler turns a raised exception into {"status": "error"}. update_fact and delete_fact behave the same way through _durable_update_or_adopt / _durable_delete.

So when Postgres is unavailable, the knowledge base can no longer accept, update or delete facts — where previously Redis alone was enough. Reads still work: _read_fact_for_write serves from the Redis projection first.

This is intentional and I would not revert it blind — reporting a fact as stored when it reached only a cache is exactly the shape of #12733, and Postgres is unconditional in every deployment (user_management/config.py:173, #10636). But it is an availability change that was never stated in the PR, and nobody has decided whether it is the behaviour we want under a Postgres outage.

The question to settle

Three defensible answers, and the code currently implements the first by default rather than by decision:

1. Fail the write (today). Correct, and the user is told immediately. A Postgres blip makes the KB read-only.
2. Queue and project. Write Redis, record the fact in a durable outbox, reconcile when Postgres returns. Keeps the KB writable; adds an outbox nobody has today, and the outbox is itself a store needing a declared authority (canonical(state): no datum declares its system of record — Redis, Postgres and ChromaDB hold the same data with no authority rule #15663's own rule).
3. Degrade explicitly. Accept the write to Redis, mark the fact as not-yet-durable, and surface that state in the UI rather than silently. Honest, but a fact that is visibly "at risk" is a product decision, not just an engineering one.

Acceptance criteria

1. The chosen behaviour is recorded in autobot_shared/store_authority.py's knowledge_facts entry, so the next reader learns it from the table rather than from a traceback.
2. Whatever is chosen is covered by a test that exercises the Postgres-unavailable path — there is none today; every existing test mocks the durable store.
3. If (1) stands, the user-facing error says the knowledge base is temporarily read-only rather than the current generic "Knowledge operation failed", which reads as data corruption.
4. If (2) or (3), the intermediate state has a declared system of record like any other persisted concept.

Related

• knowledge: browser empty + 'unvectorized on every reload' — facts (Redis) wiped 43→0 while 22 ChromaDB vectors remain; facts not durably persisted; vectorized status read from Redis flag not the vector store #12733 — the incident that motivated failing loudly.
• canonical(state): no datum declares its system of record — Redis, Postgres and ChromaDB hold the same data with no authority rule #15663 — where the behaviour was introduced.