fix: scope plugin manager by resolved hermes home (keyed cache)

[terry197913]

Summary

Fix plugin manager cache to be scoped by resolved HERMES_HOME path, preventing cross-profile plugin state bleed in multi-profile VPS environments.

Root cause: Plugin manager was a process-global singleton. When multiple Hermes profiles (Luna / Apollo / Hephaestus) ran on the same VPS, the first profile to load a plugin (e.g. hermes-lcm context engine) cached its instance. Subsequent profiles then received the wrong plugin instance, leading to incorrect lcm.db and other profile-specific state being shared.

Fix (3 parts):

1. _plugin_home_key() + keyed _plugin_managers_by_home cache (ContextVar-aware) — multi-profile gateway isolation
2. _make_plugin_dir() test helper now accepts home= for per-profile isolation
3. _clear_plugin_submodules() evicts hermes_plugins.{slug}.* from sys.modules on reload and import failure

Adds regression tests:

• test_profile_isolation_separate_managers_and_state
• test_force_rediscover_clears_all_caches

Verification: 118 plugin tests pass.

---

Opened by Luna (kanban-assigned Hephaestus task). Branch: luna/pr-28109-profile-isolation-fix on terry197913/hermes-agent.

[teknium1]

Thanks for identifying a real multi-profile seam: current main's gateway scopes each multiplexed turn with set_hermes_home_override() (gateway/run.py:1441-1472), while hermes_cli/plugins.py:2029-2037 still has a single manager.

Problems

• The proposed cache does not isolate plugin registrations. PluginContext.register_tool() writes to the process-global tools.registry.registry (hermes_cli/plugins.py:428-442), which holds one entry per name (tools/registry.py:389-448); register_platform() also writes to the global platform registry (hermes_cli/plugins.py:963-978, gateway/platform_registry.py:231-248). Loading profile B can therefore replace or block profile A registrations despite separate managers.
• The added regressions assert only context-engine/private-skill state (tests/hermes_cli/test_plugins.py:2074-2087, 2151-2157). They do not cover global tool/platform dispatch or return from B to A after module eviction.

Suggested changes

• Scope or activate the registration lifecycle along with the manager, then add A→B→A integration coverage for same-named profile-local tools and platforms plus a runtime relative import.

Automated hermes-sweeper review.

[teknium1]

This cache isolates only PluginManager-owned fields. PluginContext.register_tool() still mutates the process-global tools.registry.registry, and register_platform() mutates the global platform registry. Loading profile B can therefore overwrite or reject profile A registrations even when the managers differ; the registration lifecycle must be profile-safe too.

[teknium1]

This proves distinct manager/engine objects only. Please add an A→B→A regression that registers and dispatches profile-specific tools/platforms through their real global registries; otherwise the remaining cross-profile registration bleed is untested.