feat(history): add configurable chat history storage with MySQL persistence

[moyiliyi]

Summary

This PR adds configurable chat history modes to Notebook Intelligence.

It introduces three explicit history modes:

• none for ephemeral sessions with no restored history after refresh
• local for local history with a configurable message limit
• mysql for persistent server-side history

It also adds MySQL-backed storage for conversations, chat messages, and tool execution records, along with backend and frontend support for restoring history and listing recent conversations.

What changed

• added explicit chat history modes:
  • none
  • local
  • mysql
• added MySQL-backed storage for conversations, chat messages, and tool execution records
• associated persisted conversations with user_id, chat_id, chat_mode, and conversation_id
• used JUPYTERHUB_USER when available so persisted history can be scoped per user in JupyterHub-style deployments
• added backend APIs for loading chat history and recent conversations
• added settings UI for selecting history mode and configuring MySQL
• updated the chat sidebar to restore history based on the selected history mode
• updated chat history handling so ask and agent flows can continue from the same conversation history

Why

Before this change, chat history was effectively ephemeral: users could see messages in the current UI session, but history was lost on refresh.

This PR formalizes that behavior as none mode and adds two additional options:

• local for lightweight history restoration
• mysql for persistent, user-scoped history storage

If users do not configure MySQL, they can still use none or local mode.

The default mode is local.

If MySQL mode is selected but validation fails, the configuration is downgraded to none, and the user is notified in the settings UI.

Relation to #116

This PR mainly addresses the conversation storage and history persistence part of that discussion.

In MySQL mode, persisted conversations are associated with a user identity, using JUPYTERHUB_USER when available and otherwise falling back to the authenticated server user. That makes the storage model more suitable for multi-user JupyterHub environments than the previous ephemeral behavior.

UI Settings

none mode:

local mode:

mysql mode: