[codex] fix Photon platform plugin CLI loading

[fnoor1]

Summary

Keep explicitly enabled bundled platform plugins loadable during plugin CLI discovery so plugin-owned commands such as hermes photon setup remain available.

Also tighten gateway env auto-enable behavior so an explicitly disabled platform stays disabled even when credentials are present in the environment.

Root Cause

Bundled platform plugins are normally deferred to avoid importing every platform SDK on ordinary CLI startup. That is correct for the common path, but it also meant an explicitly enabled bundled platform could appear enabled while its plugin-owned top-level CLI command was never registered.

Separately, gateway env auto-enable only skipped disabled platform configs when an internal _enabled_explicit marker was present. User config that disabled a platform without that marker could be re-enabled by environment credentials.

Changes

• Load explicitly enabled bundled platform plugins during plugin discovery so their CLI commands register.
• Expose plugin-registered top-level CLI command specs to the main CLI parser.
• Register plugin CLI commands before argparse routing.
• Respect any existing disabled platform config during env auto-enable.
• Add regression coverage for Photon-style env enablement and bundled platform CLI loading.

Validation

• scripts/run_tests.sh tests/gateway/test_plugin_env_enablement.py tests/plugins/test_bundled_platform_plugin_loading.py
• uv pip check --python /home/fnoor1/.hermes/hermes-agent/venv/bin/python
• Live smoke: hermes photon --help

[alt-glitch]

This was generated by AI during triage.
Competes with #54717 to fix #54678 (hermes photon top-level CLI hidden when the bundled platform plugin is deferred). Different mechanism: #54717 resolves only the matching deferred platform on the unknown-command slow path before parse_args(); this PR loads explicitly-enabled bundled platforms during discovery and also hardens gateway env auto-enable. Not a duplicate — flagging the cluster for a maintainer to pick.

[teknium1]

Thanks for addressing the deferred-platform CLI regression. The current-main premise is real: bundled platforms are deferred at hermes_cli/plugins.py:1444-1446, while Photon registers hermes photon only when its adapter loads at plugins/platforms/photon/adapter.py:1789-1795.

Problems

• The proposed eager-load branch only applies when the bundled platform is in plugins.enabled. It therefore does not materialize Photon for the normal deferred hermes photon path; main() still reads _cli_commands after discovery at hermes_cli/main.py:13228-13240 without resolving the matching deferred loader.
• The gateway/config.py change removes the intentional _enabled_explicit distinction. Current YAML loading records that marker at gateway/config.py:1125-1129, and the registry pass deliberately probes non-explicit disabled entries at gateway/config.py:2181-2217 for env configuration.

Suggested changes

• Use the targeted deferred-platform resolution approach identified in the discussion of #54717, then test the loader → CLI registration → argparse path.
• Keep the explicit-disable marker guard unless a file-loaded configuration repro establishes otherwise.

Automated hermes-sweeper review.

[teknium1]

_enabled_explicit is the intentional boundary here: load_gateway_config() sets it when YAML supplied enabled (gateway/config.py:1125-1129), while the registry path later probes an existing disabled config for env-only setup (gateway/config.py:2181-2217). Removing the marker makes every non-explicit disabled entry suppress env enablement; please retain it unless a file-loaded config repro demonstrates the marker is absent for a user-authored disable.

[teknium1]

Fixed on main via PR #73498 (salvage of #54717 by @Bartok9). Closing this draft as a duplicate — thanks for taking a run at it.