Stabilize Memory Core Backend Initialization

Problem

The Memory Core initialization lifecycle suffered from critical race conditions caused by manual await instance.initAsync() calls firing alongside the framework's native constructor microtask loop. This triggered duplicate concurrent backend bootstraps (specifically in the SQLite graph database), breaking the WAL and resulting in severe locking errors during automated test execution. Additionally, the StorageRouter was being unnecessarily exposed and example scripts relied on legacy hardcoded backup directories.

Proposed Solution

1. Fix Initialization Race Condition: Replace explicit .initAsync() calls on newly instantiated services with .ready() to guarantee single-pass thread safety.
2. Encapsulate Storage Router: Update MemoryService, DatabaseService, and SummaryService to handle await StorageRouter.ready() within their own initAsync overrides, decoupling the public API.
3. Refactor Example Scripts: Standardize ai/examples/ (like db-backup.mjs and db-restore.mjs) to boot specifically via the core services instead of exposing internal managers, and point to the centralized aiConfig.backupPath instead of hardcoded dist directories.