fix: move az login and account-set to admin-only access level

[gossion]

Summary

• az login and az account set are moved from readwrite to admin-only access level
• In default readwrite mode, calling operation=login or operation=account-set now returns an error
• Tool description updated to only show these operations at admin level

Background

MSRC report: az login was exposed as a readwrite operation. An attacker with MCP tool access (or via prompt injection) could call operation=login, args="--service-principal --username X --password Y --tenant Z" to switch the system-level az CLI credential context to an attacker-controlled tenant. Unlike most defense-in-depth issues, this has persistent side effects — it writes to ~/.azure/msal_token_cache.json and ~/.azure/azureProfile.json, affecting all subsequent az CLI calls on the machine outside the MCP session.

az account set is treated the same way: switching the active subscription is a system-state change that warrants admin-level gating.

Changes

• internal/components/azaks/registry.go: removed OpLogin and OpAccountSet from readWriteOps, added both to adminOps; updated generateToolDescription to only list login/account-set at admin level
• internal/components/azaks/registry_test.go: added test cases verifying login and account-set are rejected at readonly and readwrite, accepted at admin

Severity

Low (defense-in-depth). No privilege escalation — the attacker must supply their own service principal credentials. The harm is persistent disruption of the user's az CLI context. Does not warrant a CVE.

Test plan

• go test ./internal/components/azaks/... — new access level test cases pass
• go test ./... — all 27 packages pass