[BUG] SQLite memories not loading on container startup (race condition) #94

Problem

When OpenMemory starts with an existing SQLite database, existing memories fail to load despite being present in the database file.

Symptoms:

• Backend logs show: [INIT] Initial decay: 0/0 memories updated
• Dashboard and MCP API show no memories
• SQLite database contains all memories (verified with SELECT COUNT(*) FROM memories)
• Affects SQLite backend only (PostgreSQL not affected)

Environment:

• OpenMemory v1.2.2
• SQLite backend (default configuration)
• Docker deployment with bind-mounted database
• Container restart scenario

Root Cause

Race condition: The run_decay_process() function executes immediately after module load (line 101 in backend/src/server/index.ts), before SQLite's async initialization completes.

Reproduction Steps

1. Store memories in OpenMemory with SQLite backend
2. Restart the Docker container
3. Check logs: docker logs <container>
4. Observe: [INIT] Initial decay: 0/0 memories updated
5. Verify database has data: sqlite3 ./data/openmemory.sqlite "SELECT COUNT(*) FROM memories;"

Expected Behavior

• All existing memories should load on startup
• Logs should show: [INIT] Initial decay: X/X memories updated where X = number of memories in database

Proposed Solution

Add a small initialization delay (3 seconds) before running the initial decay process to ensure SQLite connection is fully established.

Impact

This is a critical bug for users who:

• Use SQLite (default configuration)
• Have existing data
• Restart containers or upgrade versions
• Use Docker with bind-mounted databases