SessionDB: no crash recovery path when state.db is corrupted

Bug Description

When state.db is in an inconsistent state (e.g., after an unclean shutdown during a WAL write), SessionDB.__init__ catches the error and creates fresh empty tables, discarding all session history without any recovery attempt.

Root Cause

SessionDB.__init__ in hermes_state.py calls _init_schema() on startup. If the database file is corrupted or in an inconsistent state, the connection fails and _init_schema() rebuilds the schema from scratch — creating empty messages, sessions, and messages_fts tables.

There is no logic to:

1. Detect that the database was previously populated
2. Fall back to session JSON files in ~/.hermes/sessions/ for recovery
3. Preserve existing data before schema reconciliation

Expected Behavior

On corrupted/unreadable state.db, attempt to recover from session JSON files in sessions/. If recovery succeeds, rebuild messages and messages_fts from JSON. If recovery fails, log the error and rebuild empty tables (current behavior).

Environment

• Hermes v0.14.0
• SQLite WAL journal mode
• Session storage: ~/.hermes/state.db + ~/.hermes/sessions/session_*.json

Reproduction Steps

1. Run Hermes gateway for an extended session (2+ hours)
2. Force an unclean shutdown (OOM kill, kill -9, power loss)
3. Observe that state.db is rebuilt with empty tables on next startup
4. Session JSON files in sessions/ survive the crash but are not used for recovery

Possible Solution

On SessionDB.__init__ failure, scan ~/.hermes/sessions/*.json. For each JSON file not represented in the sessions table, insert messages into messages. This makes JSON files the authoritative backup of session history.

Files Likely Involved

• hermes_agent/hermes_state.py — SessionDB.__init__, _init_schema(), session persistence logic