fix(tools): don't drop a toolset from platform inference when a tool is registered into it

[designnotdrum]

What does this PR do?

On inference-based platforms — api_server (the OpenAI-compatible HTTP surface used by Open WebUI) and plugin platforms with no explicit platform_toolsets entry — _get_platform_tools() reverse-maps the platform's static composite (e.g. hermes-api-server) back to configurable toolsets using an all-tools set.issubset() test.

get_toolset() merges registry-registered tools into a toolset's resolution, so resolve_toolset("terminal") grows to include the desktop-only read_terminal after discovery, and resolve_toolset("delegation") grows once a plugin registers a tool into delegation. Platform composites enumerate static tool names and gain nothing from the registry. So the moment a tool is registered into a toolset that the static composite never listed, the subset test fails and the entire toolset is silently dropped — no log, no error. On a default api_server this drops terminal (issue #49622).

The fix compares each candidate toolset's static (pre-registry-merge) membership during reverse-mapping, via a new include_registry flag on resolve_toolset()/get_toolset(). Registry-added tools stop gating toolset inference but remain exposed (subject to their own check_fn) once the toolset is enabled — matching how explicitly-configured platforms (cli/slack/gateway) already behave. This fixes the class at the reverse-map layer rather than data-patching one composite at a time.

Related Issue

Fixes #49622

Supersedes #49626 (which adds read_terminal to the hermes-api-server composite — one symptom). This PR fixes the underlying reverse-map, so no composite needs per-tool maintenance; the composite is left unchanged.

Out of scope (distinct root causes, not this class): #35527 (discord platform-name collision with _TOOLSET_PLATFORM_RESTRICTIONS + _DEFAULT_OFF_TOOLSETS) and #55793 (plugin known_plugin_toolsets discoverability, framed by its reporter as docs + a log breadcrumb, not a behavior change). Left for separate follow-ups.

Type of Change

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

Changes Made

• toolsets.py — added include_registry: bool = True kwarg to get_toolset() and resolve_toolset(); threaded through recursion, the all/* alias, includes, and the hermes-<plugin> fallback. include_registry=False returns the static TOOLSETS view (no registry-merged tools).
• hermes_cli/tools_config.py — at the three reverse-map candidate comparisons in _get_platform_tools() (no-explicit-config branch, has_explicit_config mixed-composite expansion, and the non-configurable recovery loop), resolve the candidate toolset with include_registry=False. Universes stay registry-merged so a platform never under-counts what it actually provides.
• tests/test_toolsets.py — behavior-contract tests for the include_registry flag (static view excludes registry extras, threads through includes, all alias, registry-only toolset → empty).
• tests/gateway/test_api_server_toolset.py — regression tests: default api_server keeps terminal ([Bug]: API server default toolset drops terminal/process after terminal toolset includes desktop-only read_terminal #49622); registering a tool into an existing toolset does not drop that toolset from inference; default-off / platform-restricted toolsets stay off.

How to Test

1. _get_platform_tools({}, "api_server") now contains terminal (previously dropped because desktop-only read_terminal is registered into the terminal toolset but absent from the hermes-api-server composite).
2. Registering any tool into an existing configurable toolset no longer removes that toolset from api_server inference (covered by test_registering_tool_into_toolset_does_not_drop_toolset_from_inference).
3. Default-off (homeassistant without HASS_TOKEN, x_search without creds) and platform-restricted (discord) toolsets remain off on api_server.
4. scripts/run_tests.sh tests/test_toolsets.py tests/gateway/test_api_server_toolset.py tests/hermes_cli/test_tools_config.py -q

Verified: the two new regression tests fail without the tools_config change and pass with it; the negative-contract test passes both ways; the toolset/platform/model_tools/coding/cli/cron/web_server test surface stays green.

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(tools): ...)
• I searched for existing PRs to make sure this isn't a duplicate
• My PR contains only changes related to this fix
• I've run the relevant test modules and they pass
• I've added tests for my changes
• I've tested on my platform: macOS (Python 3.13)

Documentation & Housekeeping

• I've updated relevant documentation (docstrings on get_toolset/resolve_toolset) — or N/A
• I've updated cli-config.yaml.example if I added/changed config keys — N/A (no config keys)
• I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows — N/A
• I've considered cross-platform impact — N/A (pure resolution logic, no OS-specific paths)
• I've updated tool descriptions/schemas if I changed tool behavior — N/A

[kshitijk4poor]

Merged via #56887 — your commits were cherry-picked with authorship preserved (both fix(tools): expose static (pre-registry-merge) toolset view and fix(tools): don't drop a toolset from platform inference are now first-class commits on main under your name).

Thanks for the clean root-cause fix — solving this at the reverse-map layer (include_registry=False) rather than data-patching composites is exactly right, so no composite needs per-tool maintenance going forward. Verified: default api_server regains terminal, static view correctly excludes registry-only read_terminal/close_terminal, and default-off/restricted toolsets stay off. Mutation-checked the regression tests (reverting the fix makes them fail).

Closing this in favor of the salvage PR. Appreciate the contribution!