Add package detail types and npm dist-tags connection (monolith/S06 plan: 9/22)

What does this MR do and why?

Step 9 of the monolith/S06 "version detail" plan (work item #623231). It adds the GraphQL package detail types and the npm dist-tags connection for GitLab Artifact Registry. It targets master directly.

What it adds:

• A new ArtifactRegistryPackageDetails GraphQL union returned by the single-package field package(id:), with two arms ArtifactRegistryMavenPackageDetails and ArtifactRegistryNpmPackageDetails. Each detail arm subclasses its plain list-element type under a new graphql_name. graphql-ruby emits a subclass as an unrelated schema type.
• A distTags keyset connection mounted only on the npm detail arm, returning a new ArtifactRegistryNpmDistTag type (name, versionId, version, and id from ExposesElementId), resolved by a new NpmDistTagsResolver. It caps the page at 100 and carries its own FieldCallCount limit of 1.
• The single-package field (PackageResolver and the package field on the repository details type) now returns the detail union instead of the plain list-element union. The elements are the same value objects in the same ArtifactPresenter; only the GraphQL type differs.

Why the detail union: the packages list connection returns the plain ArtifactRegistryPackage union and can page up to 20 packages in one query. If distTags were on the plain npm type, a client could select it on every row and fan out up to 20 Artifact Registry HTTP calls from one request, and the resolver's FieldCallCount(limit: 1) guard would make such a query error rather than fan out safely. Mounting distTags only on the detail union (which the list never returns) makes selecting it under packages a schema-validation error instead. The operation-wide fan-out budget is tracked separately in #624954.

Resolver behavior

The dist-tags resolver refuses only a remote repository, matching the sibling delete mutation (a remote repository holds dist-tags as an opaque document, not rows, and Artifact Registry answers 404). A virtual npm repository is allowed. It uses the existing ArtifactRegistry::Repository#npm? predicate.

Feature flag and multiversion safety

This MR is behind the shared artifact_registry_ui feature flag, dark. It is schema text only, so there is no changelog and no user-facing i18n; the GraphQL reference docs, introspection schema, and possible_types.json are regenerated.

The Danger multiversion warning recommends a backend-first split, but that is not available here. Once the backend lands, existing query documents that still spread on the plain ArtifactRegistryMavenPackage/ArtifactRegistryNpmPackage under the single package field would spread on a type that is no longer a possible type of that field, and an impossible fragment spread is a validation error that fails the whole operation rather than nulling one field. The dark feature flag is what makes shipping the schema and the frontend spreads together safe today; the rollout must keep the backend fully deployed before the flag is enabled anywhere.

References

• Work item: #623231
• Fan-out budget: #624954
• Dist-tags source decision follow-up: #628406

Screenshots or screen recordings

N/A. Schema text only, behind a dark feature flag, with no rendered UI change in this MR.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist.