Add Artifact Registry get started, repositories, and roles pages

What does this MR do?

Adds three pages to the Artifact Registry docs section and links them from the section landing page.

Page	Covers
get_started.md	Activate the registry, claim a handle, get a role, create a repository, then publish and pull
repositories.md	Hosted, remote, and virtual types; formats; what is fixed at creation; naming; visibility; limits; error messages
roles_and_permissions.md	The four roles and their permissions, closed-by-default access, registry vs repository scope, and 403 vs 404 behavior

Covers the Get started, Repositories, and Roles and permissions rows from the issue's deliverables table.

This targets docs/artifact-registry-beta-overview, not master, because these pages link to the _index.md added in !252840 (closed). Merge that one first and this retargets to master automatically.

Related issues

Related to #626825 Parent epic: &21052

Where the content came from

UI labels and error strings are taken from the shipped code, not from the design documents, because the two disagree in places. Specifically:

• Sidebar entry, activation form, and repository form labels come from ee/app/assets/javascripts/packages_and_registries/artifact_registry/ and ee/lib/sidebars/organizations/menus/artifact_registry_menu.rb.
• Error message strings come from internal/managementapi/ in https://gitlab.com/gitlab-org/ops/artifact-registry.
• Roles, permissions, and the 403-vs-404 rule come from ADR-021.
• Limits come from ADR-004 and docs/dev/configuration-reference.md.

Three things a reviewer should check

1. The sidebar entry is "Artifact registry", with a lowercase R. That is the literal string in artifact_registry_menu.rb (s_('ArtifactRegistry|Artifact registry')), and the activation button is Enable Artifact registry. Everywhere else the product and these docs use "Artifact Registry". The docs follow the UI for the two UI labels. If the product copy is a typo worth fixing, that is a nicer fix than a docs workaround, and these two strings then need updating here.
2. Virtual repositories cannot be created in the UI. The New repository menu offers Hosted repository and Remote repository only, per create_button.vue and the comment in constants.js ("A kind with no entry - virtual, today"). repositories.md says so. Worth confirming that is still true for 19.4, because the issue's scope has virtual registries in beta.
3. Client authentication is deliberately absent. get_started.md step 4 points at the in-product Setup instructions drawer rather than showing configuration snippets. See below.

Why there is no authentication page yet

The UI's setup snippets and the service's auth specification currently disagree, so documenting either one risks publishing instructions that return 401.

	UI snippets.js (reviewed 2026-08-11)	ADR-009 and internal/auth/dispatch.go
Maven	Private-Token HTTP header	Basic auth. "Custom header authentication is not supported."
npm	_authToken set to a raw GitLab token	Bearer, using a short-lived exchanged token
Docker	docker login with a raw GitLab token	Bearer, obtained from /v2/auth/token

Both sides are recent and both were reviewed, so this needs an owner rather than a guess. Raising it on &22504. The authentication page and the per-format pages follow once it is settled.

Testing

scripts/lint-doc.sh doc/user/artifact_registry/get_started.md doc/user/artifact_registry/repositories.md doc/user/artifact_registry/roles_and_permissions.md doc/user/artifact_registry/_index.md

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

Not yet verified against a running environment. Staging is not wired up to Artifact Registry yet (#619481 (closed)), so the click paths in get_started.md are read from the code, 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.