Summary

• unlink stale gateway.pid records directly when get_running_pid() determines the recorded process is gone
• auto-classify wrapper-style user memory provider plugins as exclusive when their implementation advertises register_memory_provider / MemoryProvider
• add regression coverage for both cases

Why

Two separate foot-guns were showing up locally:

1. A stale JSON gateway.pid could survive cleanup because remove_pid_file() only deletes the file when the current process owns it. That left launchd stuck in a restart loop, repeatedly logging PID file race lost to another gateway instance.
2. User-installed memory-provider plugins under $HERMES_HOME/plugins/ were still visible to the general plugin loader. Wrapper-style plugins (repo-root __init__.py, real implementation under src/) then tried to call ctx.register_memory_provider(...) against the generic PluginContext, producing warnings like:
   • Failed to load plugin 'muninndb': 'PluginContext' object has no attribute 'register_memory_provider'

Test Plan

• pytest tests/gateway/test_status.py::TestGatewayPidState::test_get_running_pid_removes_stale_json_pid_file -q
• pytest tests/hermes_cli/test_plugins.py::TestPluginDiscovery::test_user_memory_provider_plugins_are_classified_exclusive -q
• pytest tests/hermes_cli/test_plugins.py tests/gateway/test_status.py -q

Notes

• I also ran the broader core suite locally (python -m pytest tests/ -q --ignore=tests/integration --ignore=tests/e2e --tb=short -n auto) and reproduced a large set of unrelated baseline failures; origin/main is currently red on tests.yml as well.