fix(session): surface silent SessionDB failures that cause session data loss

[LucidPaths]

Problem

SessionDB initialization and operation failures are logged at debug level or silently swallowed (except Exception: pass), causing sessions to never be indexed in the FTS5 database. session_search returns empty results for affected conversations with zero indication anything went wrong.

In our deployment, ~48% of sessions (65 out of 135) were missing from the FTS5 index. The JSON session files were written normally (separate code path via _save_session_log), but the SQLite store got nothing.

Root Cause

When the gateway restarts while a CLI session is active (or any DB lock contention during init), SessionDB() raises an exception that gets caught and swallowed:

# cli.py:1185-1190
self._session_db = None
try:
    from hermes_state import SessionDB
    self._session_db = SessionDB()
except Exception:
    pass  # <-- session silently becomes unsearchable

The agent runs fine — JSON logs are written to disk — but _session_db stays None, so _flush_messages_to_session_db() short-circuits on every turn and no messages reach FTS5.

Changes

• cli.py: Log WARNING (not debug/pass) when SessionDB init fails at both __init__ and _start_session entry points
• run_agent.py: Log WARNING on create_session, append_message, and compression split failures
• run_agent.py: Set _session_db = None after create_session failure — fail fast instead of silently dropping every message for the rest of the session

Impact

Minimal — only changes log levels and adds one None assignment. No behavioral change for the happy path. Users will now see a clear warning when session indexing fails instead of discovering it hours/days later when session_search returns nothing.