Scope deploy permissions to component names #3046

Problem

deploy_component and drop_component are super-user operations (utility/operation_authorization.ts:325, :353). They can be delegated to a role only by operation name (utility/operationPermissions.ts:136-162). An OIDC trust policy names a user and can narrow operations, but it has no project constraint (security/authn/oidc/trustPolicyOperations.ts:119-139).

So a CI identity allowed to deploy PR previews can deploy over any component, including production ones. A PR author can edit the workflow, so the identity's permissions are the only real boundary.

Proposal

A role grant that limits component operations to name patterns, for example:

components:
  deploy: ['shop-pr-*']
  constraints:
    isolated: true
    hostSuffix: .shop.example.com
    branchedDatabases: required

• The grant applies to deploy_component, drop_component, get_deployment and list_deployments, and filters get_components.
• The server enforces the constraints on every deploy made under the grant.
• Least privilege stays in the role, as discussed on feat: OIDC trusted publishing — deploy from CI with no stored credential #2173. The trust policy keeps naming a user.

Token operation scope isn't enforced on REST/GraphQL (#2201), so the preview role should hold no table permissions.

Done when

A user holding the grant can deploy and drop shop-pr-12. They get 403 for shop, for a non-isolated deploy, and for a host outside the suffix.

Part of #3042.

Update, 2026-10-07

• Document isolated applications, branched databases, and per-PR CI previews documentation#715's preview role allows deploy_component, drop_component, get_components and system_information.
• The guide has to warn that the role applies to the whole cluster, not just my-app-pr-*, and that get_components can expose any component's configuration and files.
• This issue is what lets that warning go. The read side matters too: cleanup needs to see its own previews without reading everyone's configuration.