Summary

Closes the last Phase-4 surface gap on the RBAC umbrella issue #3054. External callers (skills / channel adapters / monitoring tools) can now ask "can user X invoke tool Y on channel Z?" without having to fetch the full effective-permissions snapshot and reproduce the gate logic client-side.

Surface

GET /api/authz/check?user=<id-or-name>&action=<tool>&channel=<opt>

• Admin-only — same require_admin gate as /api/authz/effective (feat(security): RBAC effective-permissions snapshot — wire simulator (#3054) #3228).
• Response:

  {
    "user": "Bob",
    "action": "shell_exec",
    "channel": "telegram",
    "decision": "allow" | "deny" | "needs_approval",
    "allowed": true,
    "reason": null
  }

Why "single source of truth"

The handler is one substantive line: it calls AuthManager::resolve_user_tool_decision(action, Some(&user_id_str), channel.as_deref(), false) — the same function the runtime gate path calls on every tool invocation. We deliberately do NOT reproduce the four-layer intersection here; reproducing it would create a parallel implementation that could silently drift from production. If the runtime would deny the call, this endpoint says "deny" with the same reason string the model would see.

404 vs guest fallback

The runtime treats unknown senders as guests and routes them through guest_gate(tool_name). This endpoint deliberately does NOT mirror that — instead it returns 404 when the user can't be matched. Reasoning:

• This endpoint is a diagnostic for operators / external integrators
• A misconfigured channel binding ("oh I bound telegram = "12345" but the actual user id is 123450") would silently look identical to a registered user with no policy under guest fallback
• Surfacing 404 forces the caller to notice the gap

The runtime continues to use guest fallback because production traffic must always get a decision (denying with a useful reason beats hanging).

Tests (5 new)

Per the project's "禁止 build" instruction this PR is not locally cargo-checked; CI will validate. The handler complexity is minimal (one function call to a well-tested kernel method) and follows the exact pattern of the sibling effective_permissions handler that landed in #3228.

Closes #3054 punch list

After this PR merges, every Phase-4 checkbox in the umbrella issue is delivered (LDAP/OIDC was split off into #3226 to unblock the close). #3054 is ready to close.

Refs #3054, builds on #3228 (effective_permissions infrastructure).