Description

Background

In PR #13384, @roji suggested that the LINQ expression processing path should be the primary internal code path in the web search connectors, rather than converting LINQ expressions back into the legacy TextSearchFilter format for processing.

Currently, the generic ITextSearch<TRecord> methods convert LINQ expressions into the legacy TextSearchFilter intermediate, then process that filter to build HTTP requests. This means the new LINQ path depends on the old TextSearchFilter infrastructure.

Problem

This dependency direction is backwards. When the legacy ITextSearch interface is eventually retired:

• The core filter-processing logic is entangled with the legacy TextSearchFilter/FilterClause types
• Removing the old interface would require rewriting the filter-to-HTTP conversion logic
• The LINQ path — which is the future — is treated as a second-class citizen

Proposed Change

Invert the relationship so that:

1. LINQ is the primary path: Generic ITextSearch<TRecord> methods process LINQ expressions directly into a raw internal format (e.g., List<(string FieldName, object Value)>)
2. Legacy is a thin shim: The old ITextSearch methods convert TextSearchFilter into that same raw format, then delegate to the shared core
3. Core methods are filter-type-agnostic: HTTP/JSON-building methods consume the raw format, with no dependency on TextSearchFilter or FilterClause

This way, when the legacy ITextSearch interface is retired, removing it is just deleting the shim layer (ExtractFiltersFromLegacy) — no rewriting needed.

Affected connectors

• BingTextSearch.cs
• GoogleTextSearch.cs
• BraveTextSearch.cs
• TavilyTextSearch.cs

Acceptance criteria

• LINQ expression processing produces raw (FieldName, Value) pairs directly — no intermediate TextSearchFilter
• Legacy ITextSearch methods convert TextSearchFilter into the same raw format via a shim
• Core HTTP/request-building methods consume raw parameters, not TextSearchFilter
• All existing TextSearch unit tests pass
• Full solution builds with 0 errors, 0 warnings

References

• @roji's review comment on PR #13384
• Feature branch: feature-text-search-linq