Feature: Pluggable relational storage backend (PostgreSQL / MySQL) for WAL-sensitive deployments

**Label:** enhancement

### Problem
Core stores (`history.db` scroll context, `governance/audit.db`, hub DB) hardcode `sqlite3` + `PRAGMA journal_mode=WAL`. WAL depends on `-shm` mmap and is explicitly unsupported on network filesystems. In Docker Swarm / K8s HA deployments where the working dir is NFS-shared and the container **drifts between nodes**, every non-graceful kill leaves WAL for crash recovery on a filesystem with no mmap consistency guarantee — a data-integrity risk we can only mitigate operationally (grace periods + periodic `wal_checkpoint(TRUNCATE)` cron).

An external DB would remove the constraint entirely. We already run PostgreSQL/MySQL for other services; `memory_manager_backend` already proves pluggability works for the memory layer (ADBPG).

### Proposed
- Abstract the three SQLite stores behind a small repository interface; ship a Postgres (psycopg/asyncpg) driver first, MySQL optional.
- Keep SQLite as default for single-node installs — zero-config path unchanged.
- Interim ask if full support is far off: make `journal_mode` configurable (e.g. `DELETE` for NFS-safe shared volumes) — a one-line PR-level change with big HA value.

### Environment
QwenPaw 2.2.0, Docker Swarm with container drift, working dir on NFSv4 (`local_lock=none`, hard), 9 agents.

Start by locating the implementations for the history.db, governance/audit.db, and hub DB stores. Read memory_manager_backend and its ADBPG backend to understand the existing pluggability pattern. Before implementation, clarify whether the goal is the full repository abstraction with PostgreSQL first or only configurable journal_mode; done should preserve SQLite as the default and cover all three stores.

Vom Indexierungsmodell aus dem Issue-Text verfasst.