feat: migrate find_file search to support Tavily alongside Google

[manisrinivasan2k1]

Summary

Adds Tavily web search as a configurable parallel option for the find_file agent action (which finds downloadable files like PDFs, spreadsheets, etc. by filetype). When TAVILY_API_KEY is set in the environment, the handler queries Tavily first; if no matching file URLs are found, it falls back to the existing Google filetype: operator navigation path. Results from both sources are merged and deduplicated.

This is an additive migration — the existing Google-based search remains fully functional as-is.

Files changed

• package.json — Added @tavily/core dependency
• src/main/main.ts — Added tavily:search IPC handler that initializes a Tavily client and performs search queries
• src/preload/preload.ts — Exposed tavilySearch bridge method to the renderer process
• src/renderer/App.tsx — Modified find_file action handler to try Tavily first, fall back to Google, and merge/dedupe results

Dependency changes

• Added @tavily/core ^0.6.1 to dependencies in package.json

Environment variable changes

• TAVILY_API_KEY — When set, enables the Tavily search path. When absent, the handler silently falls back to the Google scraping path (no breakage).

Notes for reviewers

• The Google filetype: navigation code (lines ~2103-2121 in App.tsx) is preserved exactly as-is, just wrapped in a conditional that skips it when Tavily already found results.
• The Tavily IPC handler uses require() (lazy load) to avoid import errors if the package isn't installed.
• File URL filtering from Tavily results uses the same regex pattern as the Google scraper to ensure only direct .ext URLs are surfaced.

Automated Review

• Passed after 2 attempt(s)
• Final review: The google-filetype-find-file migration unit is well-implemented and correct. It adds Tavily as an additive parallel source for the find_file action: Tavily is tried first, and Google scraping serves as a fallback if no matching file URLs are returned. The SDK usage patterns are correct, the top-level import replaces the previously reviewed dynamic require, the IPC handler is properly guarded behind an API key check, the preload exposes the bridge method securely via contextBridge, and the renderer-side filetype URL filtering uses the correct regex escaping for its context. The package-lock.json diff includes noise from libc field removals across many unrelated packages (a side effect of regenerating with a different npm version), but this is cosmetic and does not affect functionality. TAVILY_API_KEY documentation and .env.example are covered by the prerequisite google-news-action unit. No critical or major issues found.

[alexvilelabah]

Thanks for the PRs, and for the detail in the write-ups.

I'm going to pass on these, and I want to be straight about why. Bah's main constraint is that it has to work for someone who just downloads the installer and opens it — no signup, no API key. These PRs read TAVILY_API_KEY from an environment variable, which none of my users will ever set, so in practice the Tavily path would never run for them: it would fall back to Google every time, while still adding a dependency and extra code to the agent's hot path.

As they stand, the three PRs also each register the same tavily:search IPC handler, so they can't all be merged as-is.

If Tavily ever has a keyless tier that works with no signup, I'd genuinely be interested — that's the bar for anything that ships in the default experience here.