fix(cli): install model-provider plugins under model-providers/ subdirectory (#76372)

[RelaxJonh]

Summary

hermes plugins install clones all plugins into ~/.hermes/plugins/<name>/ regardless of their kind field. The Provider Registry only scans ~/.hermes/plugins/model-providers/<name>/, so model-provider plugins installed via CLI are invisible to hermes model.

Root Cause

Two discovery systems disagree on where user-installed model-provider plugins live:

1. _install_plugin_core() in plugins_cmd.py — clones into ~/.hermes/plugins/<manifest_name>/ (flat, based on the name field from plugin.yaml). No special handling for kind: model-provider.

2. _discover_providers() in providers/__init__.py — scans only ~/.hermes/plugins/model-providers/<name>/.

Result: the general plugin loader knows about the manifest but won't import it (defers to provider system); the provider loader would import it but can't find it.

Fix

After reading the manifest in _install_plugin_core, check for kind: model-provider. If present, install into plugins_dir / "model-providers" instead of plugins_dir directly. This aligns the install path with the existing Provider Registry discovery contract.

Changes

• hermes_cli/plugins_cmd.py: +10/-1 lines — detect kind: model-provider and route to model-providers/ subdirectory

Fixes #76372

[teknium1]

Thanks for tracing the installer/provider-discovery boundary. The core premise is confirmed on current main: the installer targets the flat plugins root (hermes_cli/plugins_cmd.py:506) while provider discovery scans only $HERMES_HOME/plugins/model-providers/ (providers/__init__.py:96,166-171).

Problems

• The changed install target leaves lifecycle operations behind. cmd_update() and cmd_remove() both use _require_installed_plugin() (hermes_cli/plugins_cmd.py:647,692), which only resolves the flat location at :434. A newly installed model provider could not be updated or removed through the CLI.
• The dashboard update route also remains flat-only: _user_installed_plugin_dir() resolves under the root plugins directory (hermes_cli/plugins_cmd.py:1936-1943), and dashboard_update_user_plugin() uses it at :1948.
• No regression test accompanies this new category-specific install behavior. The present install E2E test covers only the flat path (tests/hermes_cli/test_plugins_cmd.py:575-618).

Suggested changes

• Add a shared nested lookup fallback for model-provider installations and apply it to CLI/dashboard lifecycle paths.
• Add install-placement and nested-lookup regression coverage. Issue #76372 already links PR #76387 (a81cc9cd16e732e825f668310cf849872d8514a0) with this broader shape.

Automated hermes-sweeper review.

[teknium1]

Routing installation here is necessary, but update/remove still resolve only plugins_dir / name through _require_installed_plugin() (hermes_cli/plugins_cmd.py:647,692 on current main). Please add a shared nested model-provider lookup so a provider installed here remains manageable.

[alt-glitch]

This was generated by AI during triage.

Related: #76387 implements the same install-path correction and also repairs lookup of installed model-provider plugins. This PR is narrower; maintainers should consolidate the overlapping work rather than treat it as a duplicate closure.