Proactively inform users which Manager actions they can/cannot take (security level + banned packs)

## Goal

Proactively tell the user which Manager actions they **can and cannot** take, using information we already know (or could fetch) **before** they attempt an action - so they don't waste time on installs that are going to be rejected, and when something is blocked they're told **why** and **what to do about it**.

Today the only signal for a security-blocked install arrives **after** the attempt as a 403/404. We just improved that reactive path (surfacing the backend reason in the progress toast, see #1037 / Comfy-Org/ComfyUI_frontend#12752 and #1041), but the user still has to try-and-fail. This issue tracks the **predictive** experience.

## Background: why we can't predict blocks today

The security gate is computed and enforced **only at install time**, server-side, and none of its inputs are exposed to the frontend:

- is_allowed_security_level(risk) combines three backend-only things:
1. `security_level` (`strong` / `normal` / `normal-` / `weak`) - stored in `config.ini`, **no read endpoint**
2. whether `--listen` is loopback (`is_local_mode`) - **no read endpoint** (only relaxes *high*-risk installs)
3. the pack's **risk level** (`low` / `middle` / `high` / `block`) - computed dynamically at install time by `get_risky_level` (based on whether the pack's git URL / pip deps appear in `custom-node-list.json`); there is **no per-pack risk field** stored anywhere.
- **No Manager endpoint** returns `security_level`, `network_mode`, or a "can-install" verdict.

So replicating the decision client-side is not viable - it depends on backend state and the node DB.

There is already one *unrelated* predictive signal: Comfy Registry **`is_banned`** packs surface as a `banned` conflict. That's good, but it's independent of the local `security_level` gate.

## Plan

### Phase 1 - Backend (ComfyUI-Manager): expose what we need
The predictive UX is blocked on Manager. Two complementary additions:

1. **Read the active policy.** Add a read endpoint returning the current `security_level` and `is_local_mode` (derived from `--listen`). Lets the UI show the active policy and warn generically.
2. **Per-pack / per-action verdict (dry run).** Add a `can_install` / dry-run pre-check that runs the existing `get_risky_level` logic for a given pack+version and returns a verdict (`allowed` | `blocked`) plus the reason and the required remediation (e.g. "needs `security_level` `normal-` or lower, or `--listen` on a local IP"). This is the only reliable way to gray-out a *specific* pack, since risk is dynamic.

### Phase 2 - Frontend (ComfyUI_frontend): consume and surface
- Fetch the active policy once and the per-pack verdict (or batch verdicts) when listing/searching packs.
- In the pack UI, **proactively** indicate non-installable packs: disable/annotate the Install button with a clear reason and the remediation steps, rather than letting the user click and fail.
- Reuse the existing conflict/banned presentation for consistency; add a security/policy state alongside `banned`.
- Show the active security level somewhere discoverable so users understand the current constraints.

### Phase 3 - Desktop (Comfy-Desktop): close the loop on remediation
- We now own the `security_level` setting (#1041). When a pack is blocked because the security level is too strict, the remediation message should point users to the Desktop setting that changes it (and explain the `--listen` implication), so the "what to do" is actionable in one place.

## Acceptance criteria
- A user can see, **before attempting**, that a pack cannot be installed under the current security policy, with a clear reason and concrete remediation.
- Banned packs continue to be flagged (already working) and are visually consistent with security-blocked packs.
- The active security level is discoverable, and the path to change it (Desktop setting) is surfaced in the remediation.

## Notes / scope
- This is **not** in scope for the current PRs (#12752, #1041); it starts in ComfyUI-Manager.
- Related: #1037.

Start by tracing the Manager install-time security check, including get_risky_level, and review the existing banned-pack conflict presentation in the frontend. Then map the Phase 1 policy and dry-run endpoints to the frontend and Desktop remediation work described here. Done means users see blocked packs, reasons, remediation, the active security level, and consistent banned-pack treatment before attempting installation.

Written by the indexing model from the issue text.