[feature] gcloud permissions: pick a project, read its IAM roles in-panel

[YJack0000]

permissions for gcloud used to answer "IAM roles are per-project and per-resource; patchbay does not resolve them yet" and hand back a gcloud projects get-iam-policy line to paste — a bare command where an action would have worked, which is the one thing CONTRIBUTING says the panel does not do. It now runs the read itself.

The shape change. A Google account has no roles of its own, only roles on a project, so permissions became optionally scoped, following verify_profile exactly:

• Probe::permission_scopes() and permissions_in(scope), both defaulted — the other 24 probes are untouched, gh and wrangler behave as before.
• PermissionsReport gains scope, omitted from JSON when there is none.
• gcloud implements both: projects list (skipping non-ACTIVE lifecycle states, and inserting the configured project even when it is absent from the list, since resourcemanager.projects.list is a separate grant) and get-iam-policy filtered to the active account. collect_roles/members_include walk both the flattened and unflattened policy shapes and re-check members client-side, so a role held by someone else can never be reported as yours.
• Panel: a searchable project picker (type to filter, arrows/enter, configured project preselected) that appears only once the backend says the tool has scopes. Listing execs gcloud, so nothing runs until you press the button — tier-2 discipline intact.
• pb perms gains --scope and --list-scopes; MCP get_permissions gains an optional scope beside a new list_permission_scopes tool (smoke.sh's tool-name assertion updated).
• The frontend's hardcoded PERMISSIONS_TOOLS set is gone — which tools can report permissions is the backend's fact, not a list in the UI that goes stale.

Two deliberate calls. The unscoped read resolves the active configuration's core/project and reads that — the same move verify makes with the active profile — rather than answering a question it could work out for itself. And the copyable line survives in exactly one place: when there is no gcloud on PATH, so patchbay genuinely cannot answer.

Verified. 624 workspace tests pass, including 13 new gcloud cases (projects-list parsing, active flagging, unlistable-but-configured project, IAM→roles, foreign-member rejection, empty bindings, refusal, reauth flattening, unparseable output, no-project, scoped-other-project, and a GhProbe case proving an unmodified probe returns empty scopes and delegates). fmt + clippy -D warnings (workspace and src-tauri) + bun run build clean; no lockfile change. Live-checked against real gcloud: --list-scopes lists and stars the configured project; an expired login reports one actionable sentence rather than a four-line paste of Google's reauth text.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud