Improve search

[daaain]

The custom search is a bit wonky sometimes, I'm not sure what happened, but might have got broken at some point 🤷

I'm not sure if I like that it hijacks the browser search, I'd probably change it to not use the same keyboard shortcut.

In terms of actual function, it could filter messages that contain the search term and highlight? Also, expand them all.

We should also add some browser tests to make sure it doesn't regress.

[cboos]

Yes, please! You could bind F3 instead.

[daaain]

Ran it past Claude and quite like its suggestions.

Didn't even know about using / for search on Github!

A few thoughts on direction before I touch anything:

Shortcut: Agree on dropping Ctrl/Cmd+F — / is the de-facto "search-in-page" key (GitHub, Gmail, Slack) and won't fight the browser's native find. We can keep Esc to clear and Enter/Shift+Enter for next/prev.

Filter + highlight + expand: The cleanest model is to make search a filter source — it adds a search-hidden class to messages with no matches, and an search-match class on the rest, then auto-unfolds ancestors of any match (the fold state machine already lets us flip sections to state C). Main tradeoff: hiding non-matching messages can amputate context (e.g. you find a tool result but lose the user prompt that triggered it). Two ways to handle it: (a) always keep ancestors visible alongside the match, or (b) add a "show context" toggle. I'd default to (a) — ancestors are usually small and orient the reader.

Tests: A browser test file (test_search_browser.py) modelled on test_timeline_browser.py makes sense — cover open-with-/, regex toggle, filter+expand behaviour, navigation, and persistence across reloads.

Does that direction sound right? In particular: are you OK with auto-keeping ancestors visible, or would you rather the search filter be strict (only matches, nothing else) with context as a separate toggle?