fix(cli): emit clear warning when toolset belongs to disabled category (#59547)

[SquabbyZ]

Fixes #59547

Summary

When a configured toolset belongs to a plugin that's been disabled or uninstalled, the validator was emitting a misleading 'unknown toolset' warning — often paired with a wrong hermes-<platform> typo guess that sent users hunting for a misspelling that didn't exist.

What changed

• hermes_cli/toolset_validation.py::validate_platform_toolsets() now takes an optional known_plugin_toolsets map. When a toolset name is not in the registered catalog but IS found under known_plugin_toolsets[platform] (written by _save_platform_tools), the validator emits a distinct 'plugin is disabled or uninstalled — re-enable it in plugins.enabled' warning and skips the typo guess.
• The new parameter is threaded through the single production call site in hermes_cli/config.py (post-migration validation pass) via read_raw_config().get('known_plugin_toolsets'). Defaults to None, so all 13 existing tests/hermes_cli/test_toolset_validation.py tests still pass with zero regression.
• Genuine typos still fall through to the existing generic warning (no regression).
• Zero-valid safety net from bug: config migration (v25->v26) corrupts platform_toolsets, silently kills all tools #38798 still fires when all references are stale (no regression).

How to test

# 1. Disable a plugin whose toolset is configured
hermes plugins disable my-plugin
hermes config validate                    # → 'plugin disabled' warning, NOT 'unknown toolset'

# 2. Genuine typo still caught
hermes config set toolsets.enabled herms-cli     # → existing 'unknown toolset' warning

# 3. Healthy toolset — no warning
hermes config set toolsets.enabled hermes-cli
hermes config validate                    # → no warning

Test plan

• 17 new tests in tests/cli/test_toolset_validation_warnings.py covering: disabled-plugin → plugin warning; genuine typo → falls through to generic warning; valid toolset → no warning; platform-scoped known-map isolation; malformed known_plugin_toolsets falls back to pre-fix behavior; zero-valid safety net from bug: config migration (v25->v26) corrupts platform_toolsets, silently kills all tools #38798 still fires.
• All 17 new tests pass.
• All 13 existing tests/hermes_cli/test_toolset_validation.py tests still pass (no regression).

Platforms tested

• Linux (CI-equivalent: TZ=UTC LANG=C.UTF-8 PYTHONHASHSEED=0 python -m pytest)

AI-assisted contribution

This PR was drafted as part of an automated contribution sweep driven by https://github.com/SquabbyZ/peaks-loop. The first attempt was opened against the wrong base repo (the fork instead of NousResearch/hermes-agent) and was closed before this one was opened. All code changes were generated by an AI coding assistant from the issue body — please flag anything that looks off.

[alt-glitch]

This was generated by AI during triage.

Related: this competes with the open PR #56731 for the same issue #59547 via the same approach (thread known_plugin_toolsets into validate_platform_toolsets() to distinguish a disabled/uninstalled plugin from a genuine typo). Flagging for a maintainer to pick the canonical fix.

[teknium1]

Thanks for the focused config-warning fix. The premise remains present on current main: hermes_cli/toolset_validation.py:58-66 emits the generic warning for every unloaded toolset, while hermes_cli/tools_config.py:1989-1996 already persists the per-platform plugin snapshot needed to distinguish this case.

Problems

• The new tests call the helper directly, but the behavioral change also depends on the production propagation at hermes_cli/config.py:6153-6155. There is no temp-HERMES_HOME migrate_config() regression test proving known_plugin_toolsets is read and forwarded; a wiring regression there would silently restore the generic warning.

Suggested changes

• Add a tests/hermes_cli/test_config.py migration test with both config maps and assert results["warnings"] contains the plugin-specific warning.

This is an automated hermes-sweeper review.