feat(nodejs): add Session.searchMessages() to query session history (#2376)

[Anvith433]

Summary

Implements the feature requested in #2376 — an async searchMessages() method on CopilotSession for querying inside a session's history, for the Node.js/TypeScript SDK.

async searchMessages(
    query: string | RegExp,
    options?: SearchMessagesOptions,
): Promise<SessionEvent[]>

• query — a string (case-insensitive substring by default; exact case via { caseSensitive: true }) or a RegExp (case sensitivity governed by its own i flag).
• options.eventType — restrict results to a single event type (e.g. "assistant.message"). Typed as SessionEventType | (string & {}) for autocomplete while still accepting any string.
• Returns the matching SessionEvent[] in history order.

Design notes

• Fetches history via getEvents() and filters in memory.
• Matching runs only over the string leaf values nested within event.data (message text, tool output, error messages, nested attachment fields). Structural fields (type, id, timestamp) and object keys are intentionally not searched, so a query matches content rather than field names or UUIDs.
• For a RegExp query, the pattern is cloned with the stateful g/y flags stripped, so repeated .test() calls never depend on a shared lastIndex and the caller's RegExp is never mutated.
• An empty-string query matches every event (still subject to the eventType filter).

Testing

• npm test -- test/session-search-messages.test.ts → 20/20 pass (string/RegExp matching, case sensitivity, eventType filtering, nested-data matching, lastIndex safety, caller's RegExp not mutated, order preservation, edge cases).
• npm run typecheck → clean. npm run lint → 0 errors.

Scope / alignment

I read CONTRIBUTING.md and understand that (a) feature work should be discussed with the team first, and (b) features need to be maintained in sync across all supported languages. This PR is a Node.js-first implementation opened against the existing open enhancement issue #2376 as a concrete starting point for that discussion.

If the team is open to this feature, I'm happy to:

• extend it to the other SDKs (Python, Go, .NET, Java, Rust) for parity, and
• adjust the API shape or search semantics to match your preferences.

If it's not aligned with the roadmap, feel free to close — no worries at all, and thanks for the great SDK.

🤖 Generated with Claude Code