fix: InMemoryStore fallback silently loses data on AgentDB init failure

[sparkling]

Bug

When AgentDB init fails (import error, missing file, SQLite corruption), AgentDBService silently falls back to InMemoryStore — an in-process Map<>. Writes succeed, the caller gets success: true, and all data vanishes on process restart.

The fallback pattern in every write method:
```typescript
if (this.reflexionMemory) {
try { /* real DB */ }
catch { this.reflexionMemory = null; } // PERMANENT null
}
return String(this.episodeStore.add(...)); // SILENT in-memory fallback
```

Impact

Users think data was persisted. It was not. No error, no warning. The backendName field is set to 'in-memory' but no MCP tool surfaces this to the user.

Proposed Fix

Add initError field. When init failed and a write is attempted against InMemoryStore, throw instead of silently accepting:
```
if (this.initError) throw new Error('AgentDBService in-memory fallback active — data will not persist');
```

Also add getFallbackStatus() public method for health check MCP tools.

Related: ADR-0076 controller-bridge analysis

ADR Reference

ADR-0075 Problem 5 (dead code in critical paths), ADR-0076 Track B

[sparkling]

Fixed in 83cfd45.

AgentDBService.initialize() failure now sets initError and logs DEGRADED mode via console.error (was a silent console.warn). Write methods (storeEpisode, publishSkill, storePattern) now call assertPersistent() which throws loudly with the original init error when initError is set — no more silent acceptance of writes into a volatile Map<> fallback.

Added public getFallbackStatus() method returning { backend, degraded, initError, droppedWrites } for MCP health checks. Reads (recallEpisodes, findSkills, searchPatterns) intentionally left unchanged — empty reads on degraded init are honest, not silent data loss.

Verified by 6-agent fix swarm (2026-04-15).