fix(status): show plugin-registered platforms in hermes status

[AIalliAI]

Summary

hermes status never showed plugin-registered messaging platforms (Google Chat, IRC, LINE, Mattermost, ntfy, etc.) — the Messaging Platforms section only listed built-ins.

Root cause: show_status() in hermes_cli/status.py reads platform_registry.plugin_entries(), but nothing on the hermes status code path ever runs plugin discovery, so the registry is always empty and the plugin loop prints nothing. Every other consumer of the registry (hermes_cli/gateway.py platform enumeration, gateway/config.py, cron/scheduler.py) calls the idempotent discover_plugins() before reading it.

Fix: apply the same pattern in status.py — call discover_plugins() (wrapped in try/except like the existing block) right before reading plugin_entries().

Before / after

Before (plugin platforms silently omitted):

  QQBot         ✗ not configured
  Yuanbao       ✗ not configured

◆ Gateway Service

After:

  QQBot         ✗ not configured
  Yuanbao       ✗ not configured
  Discord       ✓ configured (plugin)
  Google Chat   ✗ not configured (plugin)
  Home Assistant  ✗ not configured (plugin)
  IRC           ✗ not configured (plugin)
  ...

Testing

• Added test_show_status_discovers_plugin_platforms — stubs discover_plugins to register a fake PlatformEntry and asserts it shows up with (plugin). Fails on main, passes with the fix.
• tests/hermes_cli/test_status.py: 18 passed.
• Manually verified hermes status on a machine with bundled platform plugins: 10 plugin platforms now listed (0 before).

Fixes #44119

[AIalliAI]

Requesting maintainer review — this is ready to land from my side. Standalone fork CI is pending first-run approval here; the rollup branch in #44061 carrying this session's batch is fully green on upstream CI (all test shards, typecheck, e2e).

[teknium1]

Thanks for the focused regression fix. The premise remains present on current main: hermes_cli/status.py:473-480 reads platform_registry.plugin_entries() without first invoking discovery, while hermes_cli/gateway.py:5096-5106 uses the established idempotent discovery pattern before consuming platform registry entries.

The proposed call is consistent with hermes_cli/plugins.py:2038-2044, where discovery is explicitly idempotent. It also enables the intended lazy platform flow: bundled platform manifests register deferred loaders at hermes_cli/plugins.py:1433-1446, and gateway/platform_registry.py:266-269 resolves those loaders when materializing plugin entries. The added test exercises the missing status-path call and unregisters its fake entry in finally.

No blocking correctness or design-fit issues found. The target hunk is unchanged on current main, so this should be mechanically salvageable.

Automated hermes-sweeper review.