fix(tools): check registered web search plugins in check_web_api_key

[liuhao1024]

What does this PR do?

check_web_api_key() in tools/web_tools.py only checked hardcoded backend names (exa, parallel, firecrawl, tavily, searxng, brave-free, ddgs). Third-party plugins that register via ctx.register_web_search_provider() (e.g. Kagi) were silently dropped — the tool registry's check_fn returned False, so web_search and web_extract never appeared in the tool list.

Now checks agent.web_search_registry.get_provider() for the configured backend name before falling back to hardcoded backends.

Related Issue

Fixes #31873

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)

Changes Made

• tools/web_tools.py: check_web_api_key() now consults the web search registry for plugin-registered providers matching the configured backend name
• tests/tools/test_web_providers.py: 3 new tests covering registered plugin provider (True), unavailable plugin provider (False), and unknown backend (False)

How to Test

1. Run pytest tests/ -q — all tests should pass
2. Verify the specific scenario described above is resolved

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
• I searched for existing PRs to make sure this isn't a duplicate
• My PR contains only changes related to this fix/feature (no unrelated commits)
• I've run pytest tests/ -q and all tests pass
• I've added tests for my changes (required for bug fixes, strongly encouraged for features)
• I've tested on my platform: macOS 26.4.1

Documentation & Housekeeping

• I've updated relevant documentation (README, docs/, docstrings) — or N/A
• I've updated cli-config.yaml.example if I added/changed config keys — or N/A
• I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture and workflows — or N/A
• I've considered cross-platform impact (Windows, macOS) per the compatibility guide — or N/A

Code Intelligence

• Analyzed: tools/web_tools.py:check_web_api_key() (callers: tool registry check_fn, hermes tools CLI)
• Blast radius: LOW — only affects the tool-availability gate; no behavioral change for existing hardcoded backends
• Related patterns: agent/web_search_registry.get_provider() already used in _resolve_web_search_backend() at lines 808-812; this fix applies the same pattern to the availability check

[alt-glitch]

Competing fix with #31887 and #32465 — all three fix #31873 by adding web_search_registry lookup to check_web_api_key(). Demoted P3 per plugin-provider-demotion rule.

[teknium1]

Thanks for the focused plugin-provider fix. This is an automated hermes-sweeper review; the requested behavior is now implemented on current main by a broader shared-path fix.

• 0a9d42ce402cc1a4e12dee18a313c1db2e0a02e3 (fix(web_tools): delegate backend availability to provider registry) explicitly fixes [Bug]: check_web_api_key() hardcodes built-in backends — third-party web search plugins silently disabled #31873 and routes non-legacy provider availability through agent.web_search_registry.
• tools/web_tools.py:1050-1077 now makes check_web_api_key() consult the shared availability/registry path for configured providers.
• tools/web_tools.py:311-327 delegates non-legacy backend names to registered providers' is_available() implementations.
• tests/tools/test_web_tools_config.py:697-813, added in e4105a2ffd525d97ffacab34d044643fb252eae3, covers the custom-provider check_fn case plus backend and tool-registry behavior.

The member comment correctly identified competing fixes; main subsequently landed a more complete solution and regression coverage.