fix(web): make plugin-provided web backends selectable

[ZOLAtheCodeX]

Problem

agent/web_search_provider.py documents a user / third-party web-provider
plugin surface: a provider subclasses WebSearchProvider, registers via
PluginContext.register_web_search_provider(), and is selected through
web.search_backend / web.extract_backend / web.backend.

In practice that surface is only half-wired. tools/web_tools.py::_is_backend_available()
gates selection on a hardcoded allowlist:

if backend == "exa":   ...
if backend == "parallel": ...
# firecrawl / tavily / searxng / brave-free / ddgs / xai
return False

Any backend name not in that list returns False. So a plugin provider is
discovered and dispatchable (the registry knows it), but can never be
selected: _get_capability_backend() sees _is_backend_available(name) is
False and falls through to the auto-detect cascade, picking some other
backend. For an extract-only plugin this surfaces as a misleading
"search-only backend" or "no extract provider configured" error even though
the provider is installed, enabled, and reports is_available() == True.

Fix

Add a generic fallback at the end of _is_backend_available(): when the name
isn't one of the built-ins, defer to the web registry's own provider
is_available(). Plugin discovery is triggered first because this gate can
run before the dispatcher's own _ensure_web_plugins_loaded() (in the
extract path, _get_extract_backend() is called before discovery).

    try:
        _ensure_web_plugins_loaded()
        from agent.web_search_registry import get_provider
        prov = get_provider(backend)
        if prov is not None:
            return prov.is_available()
    except Exception:
        pass
    return False

No per-provider hardcoding — it works for any backend registered through the
documented plugin path. Built-in backends are unaffected: they return from
their existing if backend == ... branches before reaching the new code.

Testing

Verified with a local Crawl4AI extract-only provider installed at
~/.hermes/plugins/web/crawl4ai/ and enabled via plugins.enabled:

• Before: web.extract_backend: crawl4ai → _get_extract_backend() returned
  searxng (cascade fallback); web_extract failed.
• After: _get_extract_backend() returns crawl4ai; a live extract returns
  clean markdown. Built-in backends (firecrawl with a real key, searxng,
  ddgs) continue to resolve and run unchanged.

Scope

One file, +13 lines, no behavior change for existing backends.

---

🤖 Generated with Claude Code

[alt-glitch]

This was generated by AI during triage.

Duplicate of #36987 — that earlier-open PR adds the same web_search_registry.get_provider(...).is_available() fallback at the end of _is_backend_available() so plugin-registered web backends become selectable. Also overlaps #35327 (same allowlist gate). Flagging the cluster so a maintainer can pick one.

[ZOLAtheCodeX]

Thanks for flagging — agreed, this duplicates #36987 and is covered more fully by #35327 (which also adds tests and fixes the related search-only dead-end). Closing in favor of those.

One small thing that might be worth folding into whichever lands: this version calls _ensure_web_plugins_loaded() before the registry lookup, since _get_extract_backend() can run before discovery in subagent/subprocess paths — without it, the registry can still be empty at gate-check time. Either way, glad to see this getting fixed.