Validate repositories route against the resolved slug

What does this MR do and why?

Step 7 of the S10 "activation and deactivation" plan for GitLab Artifact Registry. The organization Artifact Registry repositories route now validates against the resolved slug (Artifact Registry's immutable namespace identifier), replacing an earlier placeholder stub-slug equality check.

• The controller resolves the registry only after the existing feature-flag and read-ability gate, so the flag remains a trustworthy rollback and no Artifact Registry client call is made when the flag is off or for a viewer without the read ability.
• A requested slug that does not match, and a slug the viewer may not see, both reach render_404 by the same code path, so the two responses are byte-identical and cannot be used to enumerate an organization's slugs.
• A failed resolution answers service-unavailable rather than not-found, so a bookmark to an activated registry whose state is momentarily unknown is not reported as a wrong URL. A client error and an unknown status (the Artifact Registry 404) are both treated as unavailable.
• The repositories mount now anchors on the resolved slug rather than the request path, so a catch-all sub-path serves the same app as the base route.
• The resolved registry is memoized for the duration of the request (strong_memoize_attr :resolved_registry), so the gate's equality check and the view's mount data share a single resolution instead of reading the model cache up to three times per request. This also removes any window where two reads could observe a different slug mid-request.
• The controller no longer references the stub slug constant. The constant stays because the sidebar menu and the organization model still read it; it is removed once those consumers resolve the slug too.

Review feedback

Two GitLab Duo review comments were addressed:

1. Memoizing the resolved registry to avoid redundant per-request lookups.
2. A test-coverage gap in the slug-enumeration spec, which now asserts both the member's and the non-member's responses are 404 before comparing bodies.

Feature flag

Behind the dark feature flag artifact_registry_ui (disabled by default). No changelog (dark flag). No new user-facing strings.

Merge request target

Target branch is nkannan/ar-s10-step3-resolution, not master, because Step 7 depends on the unmerged Step 3.

How to validate locally

• RuboCop: clean — 4 files, no offenses (controller, ee/lib/organizations/artifact_registry.rb, and the two specs).
• haml-lint: clean — the repositories index view.
• Controller request spec ee/spec/requests/organizations/artifact_registry_repositories_controller_spec.rb: 20 examples, 0 failures (run with RAILS_ENV=test). This covers: the mount served from a single Artifact Registry call for a matching slug, a non-matching slug returning not-found, resolution failure (client error and Artifact Registry 404) returning service-unavailable, no-mapping-row and flag-off returning not-found with no client call, a non-member returning not-found with no call, unauthenticated redirect to sign-in, and byte-identical not-found responses for an unknown slug versus one the viewer may not see (asserting both are 404).
• The :js feature spec ee/spec/features/artifact_registry/repositories_spec.rb could not be run in the local environment (no Chrome browser binary available) and runs in CI instead.

Reproduce the runnable checks:

bundle exec rspec ee/spec/requests/organizations/artifact_registry_repositories_controller_spec.rb
bundle exec rubocop ee/app/controllers/organizations/artifact_registry_repositories_controller.rb ee/lib/organizations/artifact_registry.rb
bundle exec haml-lint ee/app/views/organizations/artifact_registry_repositories/index.html.haml

References

• Work item: #608392 (closed)