Restore session during server restart and fix unhandled error in event routes

[levxn]

#5692

Summary

Queen conversation files written to ~/.hive/queen/session/{session_id}/conversations/ survive a server restart, but the server had no way to serve them afterwards. GET /api/sessions/{id} returned 404 (in-memory dict wiped), GET /api/sessions/{id}/queen-messages required a live session object, and the frontend silently created a brand-new session — orphaning the on-disk history forever.

This PR makes cold (post-restart) sessions first-class: the server recognises them from disk, the messages endpoint works without a live runtime, and the frontend restores history into the new session before the user sees anything.

---

Changes

core/framework/server/session_manager.py

Added two static helper methods that inspect ~/.hive/queen/session/ on disk without requiring a live Session object in memory:

• get_cold_session_info(session_id) — checks whether conversation files exist for a given session ID and returns {session_id, cold: True, has_messages, created_at}, or None if no data is found.
• list_cold_sessions() — scans all subdirectories under ~/.hive/queen/session/ and returns them newest-first. Used by the history endpoint.

No SQLite dependency added — the conversation directory itself serves as the index.

---

core/framework/server/routes_sessions.py

handle_get_live_session — instead of returning 404 immediately when a session is not in memory, it now calls SessionManager.get_cold_session_info(session_id) first. If disk data exists it returns HTTP 200 with {cold: true, has_messages, created_at}. A genuinely unknown session still returns 404.

handle_queen_messages — removed the resolve_session(request) live-session guard. The endpoint now derives the session directory path directly from the session_id URL parameter and reads from disk. Works for both live and cold sessions with no behaviour change for the live case.

handle_session_history (new) — GET /api/sessions/history scans all on-disk queen session directories and returns them as a list with live/cold flags. Live sessions (present in the in-memory dict) are marked live: true, cold: false; everything else is live: false, cold: true. Route registered before {session_id} so it takes priority.

---

core/frontend/src/api/types.ts

Added cold?: boolean to LiveSessionDetail so TypeScript knows about the new field without a cast.

---

core/frontend/src/api/sessions.ts

• Updated queenMessages return type to include session_id in the response shape.
• Added history() method for GET /api/sessions/history.

---

core/frontend/src/pages/workspace.tsx

Rewrote the reconnect logic in loadAgentForType for the "new-agent" path:

Before: sessionsApi.get(storedId) threw 404 → stale messages cleared → new session created → blank chat.

After:

1. sessionsApi.get(storedId) returns {cold: true} → server restarted, files are on disk.
2. New live session is created normally.
3. sessionsApi.queenMessages(oldSessionId) is called against the old cold session ID — the server reads from disk.
4. Restored messages are injected into the chat panel sorted chronologically.
5. If no messages exist on disk (truly fresh scenario), the cache is cleared as before.
6. The initial prompt is only shown as a user message when zero messages were restored (avoids duplication on restores).

---

Before / After

Scenario	Before	After
Server restarts, user refreshes	Blank chat, history lost	Prior conversation restored
GET /api/sessions/{id} after restart	404	200 with cold: true
GET /api/sessions/{id}/queen-messages after restart	404 (live session required)	Returns messages from disk
GET /api/sessions/history	404 (no endpoint)	Lists all sessions on disk
Normal refresh (server still running)	History restored	No change

---

Resolves issue #5692

[levxn]

I am making few more edits @RichardTang-Aden , I noticed another bug, getting that fixed now. Though sessions are getting restored now, the setup fails to continue conversation from there, like resuming conversation fails, working on that now, once done I shall submit this PR!