Cross Conversational Search for Chatbot Page

**Motivation:**
A student might want to not go through the hoop of talking to SAGE or had a conversation they saved for later but forgot what it was about or what the title was. Most students also don't typically change the title of the chat message to which finding conversations could get difficult.

**Problem:**
We need a way to allow cross-conversational search to occur across student chats when made to SAGE.

**Possible Implementation Steps:**
1. Fetch the conversation JSONs from localstorage and flatten each conversation into a record `{convoId, msgId, role, text, charOffsetBase}` to where we'd feed this into a inverted-index search engine (something like: https://github.com/nextapps-de/flexsearch). We won't try to use SQLite's FTS5 for this because we do have mobile users to support and that could make their phone buggy, which equals bad UX
2. Once you plug that into the indexer, you should get candidate messages returned and that correlates to which message box is returned back to the user. We can even add some highlighting to that message BUT only to the candidate message as opposed to the entire corpus (aka conversation collection)

As a bonus, try to see if you can add: Stemming/lemmatization within FlexSearch (this should differentiate between verb groups) and Typo tolerance

**Some UX things to consider:**
1. Add debouncing (similar to course discovery), try to get within ~100–150ms, and have this indexer run in the background (or async) to not cause the entire Chatbot page to lag
2. Find a way to compactly store (convoId, msgId, startOffset, endOffset) per match so you can virtualize the conversation list and scroll-to-match without rendering everything.

**Stretch Goal (check feasibility here...)**:
1. You'll need to select an on-device embedding model (maybe something like Load MiniLM-L6-v2 (or bge-small / gte-small), quantized ONNX, via transformers.js) + Run feature-extraction pipeline in a Web Worker (WASM backend for broad support, WebGPU where available) + Lazy-load model only when smart search mode
2. Reuse that flattening step and then chunk long messages into semantically coherent spans rather than whole message chains + Embed each chunk, store {convoId, msgId, chunkId, vector, textOffset} + Run indexing incrementally on idle time
3. You may persist vectors in IndexedDB (via idb-keyval) + Tag each vector with model version so future model swaps can identify stale vectors needing re-embedding
4. Embed user query in the same Worker on submit + Brute-force cosine similarity against stored vectors (only revisit an ANN if we see conversations become large or current approach is slooww) + return top-N results above a similarity threshold
5. Auto-trigger when literal search returns zero results (also allow for users to opt-in for this via some toggle within this screen) + make sure it is a seperate label (not to be mixed with literal search results)
6. Re-embed on message edit/creation + Background re-index on model version bump