…ore lookup

/skill is registered through _register_skill_group, outside the
_run_simple_slash dispatcher fixed in the parent commit. That left
two pre-auth observable behaviors:

  - autocomplete leaked the installed skill catalog to anyone able
    to invoke the command (Discord queries autocomplete on every
    keystroke regardless of who can actually run /skill).
  - the callback dispatched skill_lookup before any auth check, so
    "Unknown skill: <name>" responses differed from a successful
    dispatch -- a probing oracle for the catalog.

Refactor the existing gate into a non-responding evaluator
(_evaluate_slash_authorization) and a thin async wrapper that
preserves the old responding behavior. The autocomplete callback
calls the evaluator and returns [] for unauthorized users (sending
an ephemeral per-keystroke would be a UX disaster). The /skill
handler calls the responding wrapper before any skill_lookup so
known and unknown skill names produce identical rejections for
unauthorized users.

No behavior change for authorized users, no behavior change for
deployments without DISCORD_ALLOWED_* configured.

Three bypass paths in the slash gate were silent fall-throughs rather
than rejections:

  - DISCORD_ALLOWED_CHANNELS configured + interaction with no
    resolvable channel id (chan_id_raw is None for the guild branch):
    the entire channel-policy block was guarded by `if chan_id_raw
    is not None`, so a malformed guild interaction skipped the
    allowlist entirely and proceeded to the user check.
  - interaction.user is None with any user/role allowlist
    configured: `str(interaction.user.id)` raised AttributeError
    in _evaluate_slash_authorization and the interaction failed
    opaquely instead of producing a clean ephemeral rejection.
  - even with the evaluator above guarded, _reject_slash itself
    dereferenced interaction.user.id -- so the fail-closed branch
    that produced (False, "missing user") still crashed before the
    ephemeral could be sent. Tolerate a missing user there too,
    falling back to "?" placeholders for the log line.

Both fail-closed branches now return False with a reason string and
emit a clean ephemeral rejection. The DM path continues to be exempt
from channel gating (matches the existing on_message DM lockdown,
which has its own user-allowlist enforcement). When no allowlists
are configured, missing-user still allows -- this preserves the
"no allowlist = everyone" backwards-compat for deployments that
have not opted in to gating.

Thread parent_id continues to be merged into the channel id set,
so an allowlist or blocklist entry for a forum channel applies to
its child threads. The ignored-beats-allowed ordering was already
correct (ignored check runs after allowed and rejects regardless);
add a short comment so future readers don't reorder it.

…lures

_notify_unauthorized_slash treated any non-raising adapter.send() as
delivered and stopped the fallback chain. SendResult(success=False)
-- the dataclass returned by every gateway adapter when a send fails
without an exception (rate limit, auth refresh, network blip the
adapter handled internally) -- short-circuited Slack notification
even though no message had actually been delivered.

Check `getattr(result, "success", None) is False` after the await
and continue the loop in that case. Confirmed delivery (success=True
or no .success attribute on the result) still returns. Hard
exceptions continue to be caught and logged at debug.

Existing tests (no .success on AsyncMock return value) keep passing
because `getattr(result, "success", None)` is None in that case,
not False -- only an explicit success=False triggers the fall-through.

…views

The four Discord component views (ExecApprovalView, SlashConfirmView,
UpdatePromptView, ModelPickerView) accepted only allowed_user_ids
and used the legacy "no allowlist = allow everyone" branch when that
set was empty. Deployments that configure DISCORD_ALLOWED_ROLES
without DISCORD_ALLOWED_USERS therefore had a wide-open component
surface: any guild member who could see the prompt could approve
exec commands, cancel slash confirmations, or switch the model --
even though the same user would be rejected at the slash and
on_message gates.

Add an allowed_role_ids parameter to each view's __init__, pass
self._allowed_role_ids at every construction site, and route
_check_auth through a shared module-level helper
(_component_check_auth) so the four views can't drift apart again.
The helper applies the same user-or-role OR semantics as
DiscordAdapter._is_allowed_user / _evaluate_slash_authorization:

  - both sets empty -> allow (preserves no-allowlist back-compat)
  - user in user allowlist -> allow
  - role allowlist set + user has matching role -> allow
  - role allowlist set + interaction.user has no resolvable .roles
    (DM context, raw User payload) -> reject (fail closed)
  - otherwise -> reject

Defaults the new parameter to None / empty set so any external
callers that still pass only allowed_user_ids retain their existing
behavior.

Pin the residual auth-parity behavior fixed in the four preceding
commits so it can't regress.

tests/gateway/test_discord_slash_auth.py extensions:
  - missing channel id with DISCORD_ALLOWED_CHANNELS configured
    rejects (channel-policy fail-closed)
  - missing channel id without channel policy still allows
  - missing interaction.user with allowlist configured rejects
    cleanly (no AttributeError) and emits an ephemeral
  - missing interaction.user without allowlist still allows
    (no-allowlist back-compat)
  - thread parent channel on DISCORD_ALLOWED_CHANNELS passes
  - thread parent channel on DISCORD_IGNORED_CHANNELS rejects
  - channel listed in BOTH allowed and ignored: ignored wins
  - admin notify falls back to Slack on Telegram soft failure
    (SendResult(success=False))
  - admin notify still short-circuits on Telegram successful delivery
  - /skill autocomplete returns [] for unauthorized users
  - /skill autocomplete returns choices for authorized users
  - /skill handler rejects before _run_simple_slash dispatch
  - /skill handler produces identical rejection for known and
    unknown skill names (no catalog-probing oracle)
  - /skill handler dispatches normally for authorized users

tests/gateway/test_discord_component_auth.py (new file) covers
the shared _component_check_auth helper directly and the four
view classes that route through it:
  - empty allowlists -> allow everyone (back-compat)
  - user in user allowlist passes; user not in user allowlist rejects
  - role-only deployment with matching role passes
  - role-only deployment without matching role rejects
  - both allowlists set: user-or-role OR semantics
  - role policy + user.roles attribute missing: fail closed
  - interaction.user is None: fail closed
  - all four views (ExecApproval, SlashConfirm, UpdatePrompt,
    ModelPicker) accept allowed_role_ids and apply it correctly
  - default value for allowed_role_ids preserves the legacy
    user-only call signatures used elsewhere in the codebase

Test fixtures use placeholder ids only.

… fix)

- test_send_available_commands_update: add steer + queue to expected cmd list
- test_concurrent_interrupt x2: fix _Stub missing _append_guardrail_observation,
  add messages/pre_tool_block_checked kwargs to mock tool functions
- test_no_yes_flag_still_prompts_in_tty: fix TTY mock — stdin/stdout must
  be real MagicMock objects with isatty() returning True
- test_dockerfile_installs_tui_dependencies: add hermes-ink/package-lock.json
  COPY directive to Dockerfile
- test_send_typing: xfail (Teams SDK TypingActivityInput unavailable in CI)
- test_concurrent_inserts_settle_at_cap: xfail (flaky under xdist workers)
- test_dockerfile_materializes_local_tui_ink_package: xfail (missing feature)
- test_ws_events_rejects_when_token_required: xfail (pre-existing WS issue)