Add GraphQL write path for remote Artifact Registry settings

What does this MR do and why?

Adds the GraphQL write path for remote Artifact Registry repository settings. This is Step 3 of the monolith/S07 Phase 2 plan. Step 2, the read type, has already merged.

• ArtifactRegistryRemoteSettingsInput: a new input carrying the five writable settings fields, url, cacheValidityHours, metadataCacheValidityHours, snapshotMetadataAlwaysRevalidate and credentials.
• ArtifactRegistryRemoteCredentialsInput: a nested input with username, password and authToken, all optional, because the required set differs per package format.
• ArtifactRegistry::AcceptsRemoteSettings: a shared mutation concern that declares the settings argument once and maps it to the Hash the client sends.
• settings is wired into both the create and the update repository mutations.
• credentialsCleared is added to the existing read type ArtifactRegistryRemoteSettings.

Everything ships behind the artifact_registry_ui feature flag, which is default off. No changelog, no user-facing strings.

Three design decisions worth a reviewer's attention

Why the input is flat, not one type per format

Artifact Registry's settings object is polymorphic. The repository's format (maven, npm, docker, oci) discriminates it, and each format defines a different field set.

An earlier design used three per-format input types and made the resolver enforce that exactly one was supplied. That was dropped for two reasons. First, an update mutation carries only the repository name, not its format, so the resolver cannot tell which fields the repository defines without a second read. Second, Artifact Registry already rejects a field the format does not define, with a 400 that surfaces in the mutation payload errors.

The consequence, stated plainly: the schema no longer makes a Maven-only field on an npm repository impossible to express. A round trip refuses it instead.

The read type was already flat for the same reason, so the write side now mirrors the read side.

Key presence carries the three credential writes

Artifact Registry distinguishes three writes on the credentials key, and the mapping needs no sentinel value:

The caller sends	Artifact Registry receives	Meaning
no credentials	no key	stored credentials unchanged
credentials: {...}	the object	stored credentials replaced
credentials: null	null	stored credentials cleared

The graphql-ruby to_h on an input object returns only the keys the caller supplied, and it keeps a key whose value was explicitly null. So the mapping is to_h and nothing else. credentials is the only argument on the input that permits an explicit null. Every other argument rejects one with a validator, because Artifact Registry types them as non-nullable.

Why credentialsCleared sits on the read type

When an update changes the upstream URL and supplies no new credentials, Artifact Registry clears the credentials scoped to the old host. It reports that as credentials_cleared inside the response settings object, and omits the key on every other response, so a later read of the same repository resolves the field to null.

Because Artifact Registry puts it inside settings, the field belongs on the type that models settings. An earlier design put it on the update mutation payload instead. That did not match the contract.

References

• Issue: #618513 (closed) (covers Steps 2, 3 and 4; this merge request is Step 3 only)
• Client change this builds on, now merged: !252151 (merged)

Screenshots or screen recordings

Not applicable. This merge request changes the GraphQL schema only and adds no UI.

How to set up and validate locally

Both Artifact Registry contract gates for this path are still open, so neither the remote create nor the settings update is exercisable against a running Artifact Registry yet. The specs stub the client, so they pass regardless of the gate state.

1. Run the specs for the write path:

   bundle exec rspec ee/spec/graphql/mutations/concerns/artifact_registry \
     ee/spec/requests/api/graphql/mutations/artifact_registry \
     ee/spec/graphql/types/artifact_registry

2. Confirm the generated schema artifacts are current:

   bundle exec rake gitlab:graphql:check_docs

3. Inspect the new input in the schema reference, under ArtifactRegistryRemoteSettingsInput in doc/api/graphql/reference/_index.md.

220 Artifact Registry GraphQL examples pass locally. All four generated GraphQL artifacts were regenerated after the rebase onto master; two of them changed, doc/api/graphql/reference/_index.md and public/-/graphql/introspection_result.json.

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.