feat(plugins): register_command(override=True) to shadow a built-in command

[arminanton]

Adds an override: bool = False parameter to register_command. By default a plugin command name conflicting with a built-in is rejected with a warning (unchanged); with override=True the plugin command shadows the built-in, mirroring the override semantics register_tool already has. Lets a plugin enhance/wrap a built-in command intentionally.

[teknium1]

Thanks for extending the plugin command surface. The collision is currently rejected on main (hermes_cli/plugins.py:560-569), but this implementation does not yet provide a safe, consistent override.

Problems

• CLI reaches plugin handlers only in its post-built-in fallback (cli.py:8921-8985), and gateway does the same (gateway/run.py:10057-10072). TUI checks plugins first (tui_gateway/server.py:11892-11901), so override=True would behave differently by surface.
• Current tool overrides require an explicit, fail-closed per-plugin operator opt-in (hermes_cli/plugins.py:409-470). The new command override has no equivalent authorization boundary.
• The diff has no tests or docs update, while the current collision test is at tests/hermes_cli/test_plugins.py:1863-1872 and the documented API promises built-ins take precedence at website/docs/developer-guide/plugins/index.md:788-805.

Suggested changes

• Centralize authorized override resolution across CLI, gateway, and TUI; add a fail-closed per-plugin gate and cross-surface regression tests; then update the documented API and precedence contract.

Automated hermes-sweeper review.

[teknium1]

override=True only changes registration here. CLI and gateway dispatch built-ins before their plugin fallback (cli.py:8921-8985, gateway/run.py:10057-10072), while TUI checks plugins first (tui_gateway/server.py:11892-11901). Please add a shared, authorized resolution path and cross-surface tests before exposing this option.

[arminanton]

Rebased onto current main and made override behavior consistent + gated.

Consistent precedence across all three surfaces (sweeper): previously CLI/gateway resolved plugins only in the post-built-in fallback while TUI checked plugins first, so override=True behaved differently per surface. Added a shared get_plugin_command_override_handler(name) that returns a handler only for registrations flagged override_builtin=True, and each surface now short-circuits to it before built-in dispatch — CLI (cli.process_command, also covers the TUI slash-worker), gateway (gateway/run.py), and TUI (tui_gateway/methods_tools.py). Plain/unauthorized plugin commands still yield to built-ins everywhere.

Fail-closed operator opt-in (sweeper): command override is gated behind the same mechanism as tool override — a new commands.override capability (plugin_capabilities.py) with _command_override_allowed() mirroring _tool_override_allowed() (bundled = trusted; everyone else needs explicit consent/legacy key; any config-read failure = denied). register_command(override=True) without consent raises PluginCommandOverrideError and leaves the built-in intact.

Added a cross-surface precedence test + opt-in gate tests. test_plugins.py → 71 passed (172 across the plugin/command regression suites). Precedence contract documented in the plugins developer guide.