feat: persist chat history per user with sidebar navigation

[aizaz68]

Summary

Closes #293 — adds a Chat History section to the Streamlit sidebar so users can see and resume past conversations.

How it works

The app already generates a persistent user_id (stored in a browser cookie/URL param) but had no way to map it to previous thread IDs — they were lost the moment a new chat started.

This PR introduces a lightweight thread_registry SQLite table that records every (user_id, thread_id) pair as soon as the user sends their first message in a thread. The first message becomes the conversation title. The registry is separate from LangGraph's checkpointer and requires no schema changes to existing tables.

Flow:

User sends first message
      ↓
Backend registers (user_id, thread_id, title="first message") in thread_registry
      ↓
Streamlit sidebar calls GET /threads?user_id=... on each render
      ↓
Past conversations appear as clickable buttons, newest first
      ↓
Clicking a thread loads its full history into the chat view

Files changed

File	Change
src/memory/thread_store.py	New — SQLite thread registry with setup/register/touch/list
src/memory/__init__.py	Export thread store helpers; call setup_thread_registry() on startup
src/schema/schema.py	Add ThreadInfo and ThreadListResponse Pydantic models
src/schema/__init__.py	Export new schema types
src/service/service.py	Register/touch thread on every request; add GET /threads endpoint
src/client/client.py	Add get_threads(user_id) method
src/streamlit_app.py	Render chat history section in sidebar

Test plan

• Start fresh — send a few messages across multiple new chats, confirm each appears in the sidebar
• Refresh the page — confirm history persists (it's in SQLite, not session state)
• Click a past thread — confirm the full conversation loads correctly
• Open in a different browser tab with the same user_id URL param — confirm history is shared
• Different user_id sees only their own threads (user isolation)

🤖 Generated with Claude Code

[JoshuaC215]

Hey @aizaz68 — thanks for tackling #293. Before going further on this one: it adds a separate thread_registry table that duplicates state the checkpointer already persists, plus a fair amount of surface (new endpoint, client method, sidebar). I'd rather find a leaner design that derives the thread list from existing persistence instead of maintaining a second source of truth.

Can we hash out the approach in #293 first? @surajvariar was also looking at this. I want to get the design right before merging ~200 lines across 7 files — happy to give feedback early. Thanks for the effort here!