Add Artifact Registry reference and troubleshooting pages

What does this MR do?

Adds the remaining six pages of the Artifact Registry beta section. With this merged, every row of the issue's deliverables table is covered except the authentication and per-format pages, which are blocked (see below).

Page	Covers
virtual_registries.md	Upstream resolution order, supported public upstreams, cache windows, connection testing, credentials
delete.md	The destructive-intent contract, typed confirmation, and the two known delete defects
limits.md	Artifact size, entity count, and pagination limits, plus the error you see at each
view_usage.md	What each usage figure counts, and why two figures over the same content can disagree
troubleshooting.md	One topic per error a participant will hit
doc/api/artifact_registry.md	The GraphQL and management API surfaces

This targets docs/artifact-registry-beta-pages, the branch of !252847 (closed), because it links to and edits pages added there. It retargets automatically as the stack merges.

Related issues

Related to #626825 Parent epic: &21052

Two corrections to pages already in the stack

Both came from reading the frontend code rather than the design docs:

1. Repository delete is not on the repositories list. It lives on the repository detail page, under More actions > Delete repository (repositories/detail/repository_actions.vue). The row menu on the list only offers Edit repository (components/row_actions_menu.vue). Fixed in delete.md and get_started.md.
2. The setup drawer item is labelled "View setup instructions", not "Setup instructions", and it is in the same More actions menu. That menu also has Copy repository URL, which get_started.md now points at as the quickest way to get the registry URL.

I also moved the limits table out of repositories.md so limits.md is the single source, leaving a two-sentence pointer behind. That avoids duplicating the same numbers on two pages.

Two known defects documented as gaps

These are in the shipped API contract and a participant will hit them, so they are written up rather than left out:

• Emptying a hosted container repository through its /v2/ delete commands does not clear the 409 from a destructive=false repository delete, because those commands leave behind the row the delete conflicts with. Every retry returns 409. gitlab-org/ops/artifact-registry#371
• Deleting a virtual repository returns 500 under either destructive value, empty or not. gitlab-org/ops/artifact-registry#819

Corrections to my earlier scope notes

Two things I flagged as missing have since landed on the Artifact Registry main, so these pages are fuller than planned:

• The statistics endpoints exist: registry, per-format, per-repository, and per-version.
• repositories.downloads_count is incremented for real now. It was a no-op stub in the August snapshot I first read.

What is still genuinely absent, and is written up as a gap in view_usage.md:

• No download count is recorded for an individual artifact or version. No column exists.
• A last-downloaded date is recorded for npm only. Maven, Docker, and OCI artifacts read null even after a pull. This is stated in the OpenAPI contract itself.

Still blocked

authenticate.md and the four per-format pages are not in this MR. They wait on:

• The UI-versus-service auth contradiction raised in !252847 (closed)
• The registry URL shape, gitlab-org/ops/artifact-registry#268

Because of the second one, no page in this MR hardcodes a registry URL. Where a reader needs one, the page sends them to Copy repository URL or the setup instructions in the UI.

Testing

scripts/lint-doc.sh doc/api/artifact_registry.md doc/user/artifact_registry/*.md

• scripts/lint-doc.sh: passed on all 10 files.
• Vale at --minAlertLevel error (the CI gate): 0 errors.
• Vale at --minAlertLevel warning: 0 warnings.
• markdownlint: 0 errors.
• lychee --offline --include-fragments: 0 errors.

Not verified against a running environment. Staging is not connected to Artifact Registry yet (#619481 (closed)), so all UI paths are read from the frontend source, not walked in a browser.

Author's checklist

• Follow the:
  • Documentation process.
  • Documentation guidelines.
  • Style Guide.
• If you're adding a new page, add the product availability details under the H1 topic title.
• If you are a GitLab team member, request a review based on:
  • The documentation page's metadata.
  • The associated Technical Writer.

Reviewer's checklist

Documentation-related MRs should be reviewed by a Technical Writer for a non-blocking review, based on Documentation Guidelines and the Style Guide.

• If the content requires it, ensure the information is reviewed by a subject matter expert.
• Technical writer review items:
  • Ensure docs metadata is present and up-to-date.
  • Ensure the appropriate labels are added to this MR.
  • Ensure a release milestone is set.
• Review by assigned maintainer, who can always request/require the reviews above.