Render the remote source section on the repository edit form

What does this MR do and why?

Editing a remote repository now renders a Source section, prefilled from the repository the page loaded. It carries the upstream URL, the credential controls, and the cache windows.

The shared repository form gains a kind-specific section slot; the edit page fills it on a remote repository and leaves it empty otherwise. A hosted repository renders no Source section.

The prefill and the settings write both run through the runtime local Apollo layer (graphql/typedefs.graphql and graphql/mock_resolvers.js) rather than through the schema, so the surface is drivable in a browser ahead of the backend. That is why the query and the write document carry @client directives. The mock keys its responses off the repository name, so the states are reachable without seeding data.

Behind the disabled artifact_registry_ui flag, so there is no changelog entry.

Screenshots or screen recordings

Screenshot by format

How to set up and validate locally

1. Enable the feature flag:

   Feature.enable(:artifact_registry_ui)

2. Open the edit form for a remote repository in the Artifact Registry repositories list.

3. Confirm the Source section renders with the upstream URL, the credential controls, and the cache windows.

4. Repeat on a hosted repository and confirm no Source section renders.

Notes for reviewers

Diff size. 1400 lines changed, past the 500-line guideline. The split:

Group	Files	Lines
Production (ee/app/assets/**)	8	+547 / -6
Specs (ee/spec/frontend/**)	5	+817 / -16
locale/gitlab.pot	1	+42

Specs are 58% of it and the regenerated .pot is mechanical, leaving roughly 540 lines of reviewable production code. Splitting further would mean landing the section without the local Apollo layer that feeds it, or without its tests — neither is reviewable on its own.

Documentation. No user-facing documentation, because nothing is reachable while artifact_registry_ui is disabled. Documentation lands with the flag rollout.

End-to-end. The diff adds data-testid selectors, so e2e:test-on-omnibus-ee should run. The surface sits behind a disabled flag, so no existing scenario exercises it.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.

Tests

Jest, 44 suites and 1257 tests green across ee/spec/frontend/packages_and_registries/artifact_registry. New and updated specs cover the section, the form slot, the edit page, the local resolvers, and the query documents.

Related to #618514 (closed)