feat(FN-1771): add dashboard memory settings UX with backend selector and capability-aware editing

- Add /api/memory/backend endpoint returning current backend, capabilities, and available backends
- Create useMemoryBackendStatus hook with polling and frontend-friendly interface
- Add MemorySettingsSection to SettingsModal with backend selector dropdown
- Implement capability-aware UI: readonly backends disable save, fallback on unknown types
- Add comprehensive tests for API endpoints and hook behavior
- Update architecture docs with memory backend architecture section

docs/architecture.md

@@ -181,6 +181,7 @@ Fusion includes a pluggable memory backend system for storing durable project le
 |---------|------|-------------|
 | `FileMemoryBackend` | `file` | Read/Write, Atomic writes, Persistent |
 | `ReadOnlyMemoryBackend` | `readonly` | Read only, Non-persistent |
+| `QmdMemoryBackend` | `qmd` | Read/Write, Persistent, CLI-based with file fallback |
 
 **Backend registration:**
 ```typescript
@@ -197,6 +198,13 @@ const backend = resolveMemoryBackend(settings);
 - `memoryEnabled`: Toggle controls whether memory instructions are injected into prompts
 - `memoryBackendType`: Select which backend to use (`file`, `readonly`, `qmd`, or custom). Unknown types are accepted and persisted verbatim; the system falls back to `file` at runtime.
 
+**QMD Backend Fallback Behavior:**
+The QMD backend (`qmd`) routes operations through the `qmd` CLI tool. When QMD is unavailable or fails:
+- Exit code 127 (binary not found): Falls back to file backend
+- Command timeout (30s): Falls back to file backend
+- Exit code 1 (general error): Falls back to file backend
+- Other exit codes: Throws error without fallback
+
 **Dashboard API:**
 - `GET /api/memory/backend` — Returns current backend status and capabilities