Summary

Closes two gaps deferred from PR #3229 (RBAC M3 per-user policy editor):

Gap 1 — UserView exposes no policy summary

The user list view (GET /api/users) returned only name / role / channel_bindings / has_api_key. With M3 in production, operators want to see at a glance which users have a non-default tool_policy / memory_access / budget without having to click into each row.

Server-side: UserView gains three booleans:

• has_policy — true when tool_policy OR tool_categories OR channel_tool_rules is set
• has_memory_access — true when memory_access is set
• has_budget — true when budget is set

These are summaries, not bodies — the per-user detail endpoints (GET /api/users/{name}/policy, the budget API) remain the only paths that expose policy contents. This keeps the list payload bounded and narrows the disclosure surface for callers that only have list-read.

Dashboard: UserItem type + UsersPage.tsx row layout updated. New badges (Policy / Memory / Budget) render alongside the existing role and API key badges using the same <Badge variant="info"> styling, with lucide-react icons (ListChecks / Database / Wallet) and title="" tooltips for context.

Gap 2 — Channel rules editor only exposes 4 default platforms

UserPolicyPage.tsx hard-coded telegram / discord / slack / email. The kernel side accepts arbitrary channel adapter names (e.g. wechat, matrix), but admins had no way to add or remove rules for them via the dashboard.

What changed:

• New + Add channel inline input + button below the channel rules table. Submitting on Enter or click adds an empty rule slot.
• Client-side validation: trim/lowercase the key, refuse empty, refuse duplicates.
• Non-default channel rows gain a remove (X) control with a (custom) label so operators can clean up typos. Defaults stay un-removable so the form remains familiar.
• The existing form-init spread already surfaced extra channels that were on the user, but they were undeletable until now.

API surface unchanged — server-side validators already accept arbitrary channel names.

Why summary booleans, not contents?

• The list endpoint may return many users; embedding the full tool_policy / memory_access / budget object per row would balloon the payload proportionally.
• A future caller token might be scoped to "read users list" but not "read policy" — the booleans give them enough to render a UI hint without leaking the rules themselves.
• The detail endpoints already exist and are the right place for the contents (cache-keyed, invalidated on mutation, etc.).

Test plan

Server-side (added to crates/librefang-api/tests/users_test.rs):

• users_list_summary_flags_reflect_policy_state — seeds two users (one bare, one with tool_policy + memory_access + budget); asserts the booleans flip only on the configured user.
• users_list_summary_does_not_leak_policy_contents — seeds a customized user; asserts the JSON response contains has_policy / has_memory_access / has_budget but NOT tool_policy / tool_categories / memory_access / channel_tool_rules / budget / api_key_hash.

UI: no JS tests added (matches PR #3229's scope) — diff stays small.

Files touched

• crates/librefang-api/src/routes/users.rs — UserView + From<&UserConfig>
• crates/librefang-api/tests/users_test.rs — two new tests (~140 lines)
• crates/librefang-api/dashboard/src/api.ts — UserItem type + 3 fields
• crates/librefang-api/dashboard/src/pages/UsersPage.tsx — three new badges
• crates/librefang-api/dashboard/src/pages/UserPolicyPage.tsx — add/remove channel UI
• openapi.json — regenerated UserView schema

Notes / follow-ups

• openapi.json was hand-edited to match what openapi_spec_test::generate_openapi_json will write on next run. CI will rewrite it; my hand-edit is just to keep the committed file in sync with the source.
• Did not touch UserConfig, persist_users, or any write paths — purely additive on the read side.
• Channel-key normalization is intentionally loose (trim + lowercase). The kernel accepts arbitrary strings; we don't want the dashboard to be stricter than the daemon.