feat(gateway): pass sender context (opt-in) to plugin slash command handlers

[TTomas78]

Problem and behavior

Plugin slash commands on upstream receive only raw arguments, so an identity/RBAC command cannot identify its invoking gateway user. This proposal supplies a context dictionary containing user_id, user_name, chat_id, chat_type and platform from SessionSource.

Handlers with at least two required positional parameters, or handlers accepting *args, receive (raw_args, context). A single-argument handler, an optional second parameter without *args, or an unavailable signature retains the one-argument call. Variadic handlers receive an additional argument compared with upstream.

The implementation uses gateway/run_inbound.py with a focused helper in gateway/plugin_commands.py. Async results are awaited, and handler TypeErrors never cause a retry. Context delivery is gateway-only; the developer guide documents the contract.

Fixes #91526. Related alternative: #56782; discussion: #51555.

Validation

Windows/Python 3.11.14, upstream 33a30fdd81, canonical scripts/run_tests.sh with isolated Hermes homes:

• 50 tests passed across command context, slash access, slash access dispatch destructive-command confirmation, session environment and off-loop command execution.
• 12 command-context cases exercise real registration and gateway dispatch, including fixed-arity, variadic, async variadic, bound methods, partials, decorators, optional parameters, unavailable signatures and no retry after TypeError.
• Ruff on helper/tests and git diff --check passed.

The full suite and live messaging integrations were not run.

[alt-glitch]

This was generated by AI during triage.

Related to #56782 and #51555, which cover the same plugin-command context need with different API contracts. #91527 uses opt-in handler arity and a sender-context dict; #56782 uses explicit registration metadata and broader keyword context. Maintainer direction can select or consolidate the public API.

[TTomas78]

Noting for maintainers: this PR takes an opt-in-by-introspection approach — a plugin handler declares def my_handler(args, sender=None) and the gateway injects sender context automatically. This keeps the change surface minimal: existing plugins need no changes, and new ones opt in by adding a single parameter. #56782 takes a different approach (explicit wants_context=True at registration time, with broader **gateway_context kwargs). Both solve the same problem; happy to consolidate if maintainers prefer one contract over the other.

[TTomas78]

Updated against upstream 7b660e66ee and resolved the gateway refactor conflicts. Command dispatch now uses gateway/run_inbound.py and the helper in gateway/plugin_commands.py, preserving this PR's proposed behavior.

Validation on Windows/Python 3.11.14 using scripts/run_tests.sh: 35 tests passed across 4 targeted gateway files, including 12 command-context cases covering fixed-arity and variadic handlers, async handlers, decorators, partials, and error handling. Ruff and git diff --check also pass. The full suite and live messaging integrations were not run.