Add artifact registry runtime Apollo mock

What does this MR do and why?

MR 1 of 3 in the monolith/S07 Step 6 chain (Vue create flow). This one adds no user-visible behavior — it is the data substrate the other three build on.

This change is behind the feature flag :artifact_registry_ui (default off).

The Artifact Registry GraphQL schema does not exist yet, so the frontend needs a data source before any view can render. The monolith documents the @client directive as the way to ship a frontend query ahead of its backend, but @client on its own registers no resolvers — those fields render nothing in a real browser. Registering runtime resolvers through createDefaultClient is what makes the slice exercisable and reviewable now instead of after the backend lands.

Changes

• graphql/mock_resolvers.js — runtime local resolvers for the repositories connection and the create mutation. The store is seeded empty and holds module state rather than writing to the cache, so a post-create eviction refetches what was created instead of dropping it. It also reproduces Artifact Registry's name rejections, so a name the real service would refuse is refused here too.
• graphql/typedefs.graphql, graphql/cache_config.js — the local schema for the @client entities, and keyFields: ['name'] on ArtifactRegistryRepository. The type carries no id; ADR-009 makes the name unique and immutable within the namespace.
• graphql/mutations/create_repository.mutation.graphql — the whole mutation field carries @client, so graphql-verify reports it as a client query and skips it.

What the mock rejects, and why the guard order matters

The contract (api/openapi/v1.yaml) declares RepositoryName as minLength: 1, maxLength: 255, pattern: ^[a-z0-9](?:[a-z0-9._-]*[a-z0-9])?$. The minLength is unviolatable independently — the pattern already requires at least one alphanumeric character — so an empty name is refused by the pattern check and needs no separate rule.

A missing name does need one, though, and it runs first: RegExp.test coerces its argument, so testing undefined matches the pattern as the string "undefined", which is valid lowercase letters. Without an explicit typeof name !== 'string' guard the mock would accept a repository literally named undefined. Artifact Registry answers 400 name is required there, so the mock returns the same, and both undefined and null are covered by specs.

• constants.js — the contract bounds, transcribed from api/openapi/v1.yaml as implemented in internal/managementapi/create.go: a name is 1 to 255 lowercase alphanumeric characters optionally separated by ., _, or -; a description is at most 1024.
• repositories/index.js — threads the resolvers, cache config and typedefs through createDefaultClient, keeping the real cache policy in its own const so deleting the mock is a small diff.

Why ship the mock merged rather than as a patch

The frontend guide suggests offering local resolvers "as a patch that reviewers can apply in their GDK". That cannot back a demo on an environment where the flag is already enabled. ee/app/assets/javascripts/cd/graphql/mock_resolvers.js is the precedent for merging one, and this follows its shape: a header comment naming the exact removal steps, and mock policy segregated from real policy. Removal is tracked in a follow-up issue.

Screenshots or screen recordings

No UI changes. Nothing queries these resolvers yet; MR 2 and MR 4 do.

How to set up and validate locally

1. bundle exec rake "gitlab:graphql:validate[ee/app/assets/javascripts/packages_and_registries/artifact_registry/graphql]" — the create mutation should report SKIP … client query.
2. yarn jest ee/spec/frontend/packages_and_registries/artifact_registry — green.
3. The resolvers are unit-tested end to end through client.mutate in graphql/mock_resolvers_spec.js, including the duplicate-name and invalid-name paths.

The chain

master ─→ MR 1 ─┬─→ MR 2  repositories list reads from local state
                └─→ MR 3  hosted repository create form

Merge order: MR 1, then MR 2 and MR 3 in either order.## MR acceptance checklist

Evaluate this MR against the MR acceptance checklist.

• No changelog: dark behind a default-off feature flag.
• No backend code, no database surface, no documentation change.

---

Written by GitLab Duo