feat(tui): add interactive session search

[albertdbio]

Issue for this PR

Closes#4714

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

Adds interactive incremental search over the current session transcript — readline/less-style rather than a modal prompt.

Press ctrl+r and a search bar attaches to the top of the prompt input:

 │ …transcript scrolls live to the nearest match as you type… │
│ │
┃ markdown_hash 3/17 ↵ keep · esc back ← search bar
┃ > prompt input (untouched) ← prompt

Behavior

• Typing live-jumps the viewport to the nearest match at-or-above your position (reverse-i-search semantics); refining the query stays on the current match when it still matches
• ctrl+r/up = older match, ctrl+s/down = newer, wraparound with a 3/17 counter; bar turns red on zero matches
• esc/ctrl+c cancels and restores the exact scroll position (sticky-bottom aware); enter accepts and keeps position; ctrl+r on an empty bar recalls the last query
• Smartcase (any uppercase in the query = case-sensitive), literal matching, unicode-safe offsets
• Matches are occurrence-level (a term appearing 5x in one long reply is 5 distinct stops) with soft-wrap-aware row estimation so matches center on screen
• Also available as /search, /find, and command palette entries; search state resets on session switch

In-place highlighting (including inside markdown)

Markdown prose and code blocks render through CodeRenderable, so this uses its public onHighlight hook to append match spans to the tree-sitter highlights — no opentui changes needed. Non-active matches render in a neutral tone, the active match in warning (bold), via two new syntax scopes (search.match, search.match.active). User messages get the same treatment with text spans. Highlighting only engages when total hits <= 200 so broad one-letter queries don't re-highlight every part per keystroke.

Keybind note (deliberate, happy to change)

messages_search defaults to ctrl+r, and session_rename moves to none (still available in the command palette and remappable). Rationale: reverse-search muscle memory is strong, and rename felt like a lower-frequency action to hold a prime binding. If you'd rather keep rename on ctrl+r, I can default search to <leader>/ or anything else — one-line change.

Related prior art: #34297 takes a dialog-based approach with message-level granularity; this PR went inline/incremental after reading the feedback in #4714 about UI placement.

How did you verify your code works?

• bun test from packages/tui (25 new unit tests over the pure search core: unit collection mirroring rendered content, occurrence offsets/lines, smartcase, regex-literal escaping, astral unicode offsets, wraparound, viewport-relative initial-match selection, highlight tuples, soft-wrap row estimation) — 217 pass
• bun typecheck from packages/tui — clean
• Extensive manual TUI testing in a real terminal: open, live jump, cycle+wrap, esc restore, ctrl+c close, empty-bar recall, 0/0 state, smartcase, in-markdown highlight rendering (prose + code blocks), active-match cycling, streaming sessions, session switching, light/dark theme input visibility

Screenshots / recordings

Happy to attach a recording if useful.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

Found related PR:

• PR feat(tui): add session search #34297: feat(tui): add session search

  • feat(tui): add session search #34297

  This PR is explicitly mentioned in the current PR description as prior art that "takes a dialog-based approach with message-level granularity." The current PR (36526) is a different implementation approach—inline/incremental search rather than modal—based on feedback in issue [FEATURE]: TUI - Search for and find string in session buffer #4714.

These are related but not duplicates; they represent different design choices for the same underlying feature (session search).

[github-actions]

Automated PR Cleanup

Thank you for contributing to opencode.

Due to the high volume of PRs from users and AI agents, we periodically close older PRs using automated criteria so maintainers can focus review time on the most active and community-supported contributions.

This PR was closed because it matched the following cleanup criteria:

• The PR was created more than 1 month ago
• The PR had fewer than 2 positive reactions
• Positive reactions are counted as thumbs-up, heart, celebration, or rocket reactions on the PR

PRs created within the last month are not affected by this cleanup.

If you believe this PR was closed incorrectly, or if you are still actively working on it, please leave a comment explaining why it should be reopened. A maintainer can review and reopen it if appropriate.

Thanks again for taking the time to contribute.