MCP Memory Tools Cache Stale Data After CLI Writes

## Description

Follow-up to #967. After the SQLite backend unification fix, a secondary issue was discovered: MCP memory tools cache the database in memory and don't see entries written by CLI commands during the same session.

## Root Cause

The `initDatabase()` function in `memory-tools.js` caches the database after first load:

```javascript
async function initDatabase() {
if (db && dbPath === findDatabasePath()) {
return db; // ← Returns stale cached copy
}
// ...
}
```

Since the MCP server is a long-running process while CLI commands are separate processes:
- MCP loads database at startup → cached in memory
- CLI writes new entry → writes to disk
- MCP retrieve → returns stale cache, doesn't see CLI entry

## Observed Behavior

| Scenario | Result |
|----------|--------|
| MCP stores → CLI reads | ✅ Works (CLI loads fresh) |
| CLI stores → MCP reads (before MCP start) | ✅ Works |
| CLI stores → MCP reads (after MCP start) | ❌ Fails (stale cache) |

## Proposed Fix

Use file modification time (mtime) to detect when CLI has written to the database:

1. Cache the database AND the file's mtime
2. On each operation, `stat()` the file (~0.1ms)
3. Only reload if mtime changed
4. After MCP writes, update cached mtime (don't reload own writes)

**Performance:**
- Fast path (no file change): ~7-8ms per operation
- Reload path (CLI wrote): ~few ms extra to reload 176KB file

## Related

- #967 - Original MCP/CLI backend mismatch issue
- #968 - SQLite unification PR

Start in memory-tools.js at initDatabase() and trace how MCP operations reuse the cached database. Check how file mtime can be recorded and refreshed after MCP writes, then verify the CLI-stores/MCP-reads scenario and the existing MCP-stores/CLI-reads behavior. Done means MCP observes CLI writes during the same running session without unnecessarily reloading unchanged data.

Written by the indexing model from the issue text.