fix(cli): flush conversation messages to SQLite on Ctrl+C exit

[liuhao1024]

Problem

When using hermes chat (CLI mode), pressing Ctrl+C at the idle prompt exits without persisting conversation messages to the SQLite session database. The session row is created and end_session() sets ended_at/end_reason, but the messages table remains empty.

This means:

• hermes --resume <session_id> shows 0 messages
• Session history is silently lost
• message_count in the sessions table can be non-zero while actual messages are 0

Root Cause

The finally block in HermesCLI.run() (cli.py) calls end_session() to close the session row, but never calls _flush_messages_to_session_db() to persist the conversation history. The flush only happens during normal conversation flow via run_agent.py::_persist_session(), which is never invoked when the user exits at the idle prompt.

Fix

Add a _flush_messages_to_session_db() call in the finally block before end_session(), guarded by:

• conversation_history is non-empty
• agent exists and has the flush method

The flush is wrapped in try/except so failures don't block the rest of the cleanup (session close, plugin hooks, etc.).

Testing

4 unit tests covering:

1. Messages are flushed when conversation history exists
2. No flush when history is empty
3. No crash when agent is None
4. Flush exception doesn't block end_session()

Fixes #44281

[teknium1]

Thanks for this! It's a duplicate of the same bug fixed in #50004 (CLI session lost on SIGHUP/SIGTERM/window-close, issue #6481).

We went with the implementation salvaged from #26894 (submitted earlier, May 16) because it uses _persist_session() — which writes both the JSON log and SQLite — and prefers the agent's live _session_messages so the interrupted in-flight turn is captured, not just the lagging conversation_history. Your fix targeted the same finally-block gap and was a correct diagnosis; it just covered the SQLite-only half via _flush_messages_to_session_db.

Closing in favor of #50004. Appreciate the contribution.