docs(roles): say which operations a role allowlist can grant

[dawsontoth]

Companion to HarperFast/harper#2809, which makes a role's operations allowlist grant deploy_component, restart_service, set_configuration, the status operations, and the other operations it silently refused (their authorization entries had no API name, so the allowlist checked a handler name no role can list).

• reference/users-and-roles/overview.md (Operation Permissions): the canonical-name rule for the eight aliased operations, the super_user operations a listing still cannot grant (secrets, OIDC trust policies, get_deployment_payload, managed backups, get_backup, read_transaction_log, and the legacy catchup, which harper#2809 now refuses), and, under the existing v5.3.0 badge, that the twenty operations earlier releases refused are granted as listed now.
• release-notes/v5-lincoln/5.3.md (Operation Allowlist Enforcement): the upgrade effect, since a role that already lists one of those operations gains it without an edit.
• reference/operations-api/operations.md (OIDC trust policy scope): a least-privilege deploy role (deploy_component plus get_deployment), and why literal registry/git tokens still need super_user on a node with secret custody.

Version badge: harper#2809 merged after v5.3.0-beta.2, which is still the newest tag, so the change ships in v5.3.0.

Verification

prettier --check passes on the three changed files, and CI's Format, Lint, TypeScript and Workflow Tests checks pass. The Docusaurus build passes inside Deploy PR Preview; only that job's upload to the preview host has failed, on the host's storage (out of disk quota, then a missing blob), not on this change.

🤖 Generated with Claude Code

[gemini-code-assist]

Code Review

This pull request updates the documentation and release notes for Harper v5.3.0 to clarify operation permissions. It highlights that twenty previously restricted operations, such as deploy_component, can now be granted by listing them, enabling least-privilege CI deployment. It also details how aliased operations are handled and lists operations that remain restricted. The review feedback suggests splitting a security warning regarding literal credentials into separate sentences to improve readability and ensure critical security advice is easily scannable.

[cb1kenobi]

No confirmed blocking issues were found on the changed lines. The existing readability concern was addressed and is not repeated.

—
Reviewed 78167fa

[kriszyp]

_{🤖 Reviewed with Codex}

[cb1kenobi]

No new blocking findings were found. The existing permission-validation concern is already raised on the affected code path and is not repeated.

—
Reviewed 78167fa

[cb1kenobi]

The latest commit fixes the allowlist-storage wording already raised on the users-and-roles overview. The docs now say a role can store a known non-grantable name while the call is still refused, and that the twenty previously silent operations are granted as listed on upgrade. The literal-token caveat remains its own sentence. No remaining blocking contradiction was found on the changed lines.

—
Reviewed cf1e886