Draft: Gate the detail kebab

What does this MR do and why?

This is step 10 of 11 of monolith/S15. It is stacked on the target branch, so once that branch merges, the diff here shows only this step.

The repository detail header now passes the userPermissions block down to the kebab menu on that page, the same block already reaching the list row kebab and the header Edit button in earlier steps. This closes the last gap where a denied user could still see write actions on the detail view.

The Delete repository item and the Clear cache item each render only when the block gives an explicit true for their matching permission, using the same permissionAllows helper and constants added in Step 6. Copy repository URL stays ungated, since it only depends on whether the instance has a client base URL configured, not on a permission verdict. When neither gated item applies and no client base URL is set, the kebab now renders no toggle at all. An icon-only toggle that opens on an empty list would be a focusable control with nothing behind it, so removing the toggle avoids a dead end for keyboard and screen reader users. A denied item is removed rather than shown disabled, because a disabled control would confirm the operation exists (ADR-021 existence hiding).

The permission verdict is advisory only. Artifact Registry still authorizes every write itself, so the component keeps dispatching the clear cache and delete mutations even when the verdict says allow and the backend then denies, and the existing error alert still shows. Specs pin this behavior for both actions. A feature spec adds two accessibility checks, on the list and on the detail page, confirming the gated controls disappear and the page stays axe clean when every verdict is denied.

Everything here is dark behind the default-off artifact_registry_ui feature flag. There is no changelog entry for that reason.

References

• #628427 (closed)
• gitlab-org#23504 (closed)
• Tracking work item: #627317
• Stacked on !254906 (closed), which must merge first
• https://gitlab.com/gitlab-org/ops/artifact-registry/-/blob/main/docs/specs/monolith/S15-permission-gated-controls.md

Screenshots or screen recordings

Screenshots of the gated state are not available yet, because the dev rig's Artifact Registry answers 503 to permission reads. See gitlab-org/ops/artifact-registry#1297 (closed). The behaviour is covered by the Jest specs in this MR.

How to set up and validate locally

1. In a Rails console, enable the feature flag:

   Feature.enable(:artifact_registry_ui, organization)

2. Run the RSpec feature spec:

   bin/rspec ee/spec/features/artifact_registry/repositories_spec.rb

3. Run the Jest specs:

   yarn jest ee/spec/frontend/packages_and_registries/artifact_registry/repositories/detail/repository_actions_spec.js ee/spec/frontend/packages_and_registries/artifact_registry/repositories/detail/repository_detail_spec.js

4. Open the organization's Artifact Registry detail page. The gated control requires an AR deployment that answers permissions.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.