docs: monolith/S10 self-serve activation spec revision and implementation plan

What does this MR do and why?

Lands two documents for monolith/S10 (activation, disable, and enable): a revision of the spec, and the implementation plan that decomposes it.

Per the plan-MR gate, no step MR opens in the monolith until this merges.

The spec revision

Phase 1 activation was operator-triggered, because the billing anchor AR requires has no authoritative source until the purchase flow lands. Deriving the anchor from the organization's sole top-level group removes the reason to keep a human in the loop: nobody types the permanent, invisible, uncorrectable value. So the owner-facing setup page moves from Phase 2 into Phase 1 and the owner supplies only the handle.

The cost, stated in the spec rather than left to a reviewer: an organization holding zero or several top-level groups cannot activate at all. That is a shape the product expects, and it becomes the Phase 2 item, because a wrong anchor is worse than a refusal when the value can never be corrected.

Also revised:

• The GitLab API surface is four methods on the existing monolith/S02 client, not a second client class, with the two-credential cost named. Building them stays with monolith/S02 as the later client phase its own Out of scope already reserves; S10 keeps the contract and criteria 27-31.
• The landing route redirects whenever the handle resolves, whatever the status, so the repositories route is the single surface that explains registry state rather than two surfaces with wording to keep in step.
• The disable and enable endpoints are contracted and implemented, so no part of the slice waits on an AR-side change.

The plan

15 monolith MRs off two roots - the mapping table, and a registry URL composition seam that depends on nothing. Execution follows the Depends on: DAG rather than the numbering; the Mermaid graph in Implementation Steps is the authority.

The cached handle-and-status resolution is the seam most steps hang off: the GraphQL field, the repositories route, the navigation and the overview link each need the resolved handle and nothing else, and the spec makes that correctness rather than convenience, since the flag and ability check must precede any AR call at every consumer.

Decisions worth a reviewer's attention, each with its rejected alternative in the plan text:

• The cache rescues its own failures. No monolith precedent caches a failure through Rails.cache.fetch, so the plan writes the rescue. The marker records which typed exception produced it, so an AR 401/403 stays distinguishable from a 5xx after a cache read and not only on a live call.
• The registry URL is composed once, in the AR-tree-root utils.js beside the monolith/S04 copy-URL builder, so the unsettled path shape lives in one file. Extracting that as its own step is also what stops Steps 10 and 12 from each creating the same derivation with no edge between them.
• The setup page splits into an owner-only route and mount and the claim form it hosts, mirroring the settings route-gate-then-body shape.

Accepted code smells the plan names rather than leaves to be rediscovered: four mixed-language MRs pairing Ruby with Vue, and the handle syntax rule written twice because a Ruby regex cannot be shared with the browser.

Review notes

• Every step is EE-only apart from Step 1's migration and transfer-support registration, which have no ee/ equivalent, and the regenerated GraphQL and i18n artifacts.
• Every step ships its own RSpec/Jest and gates on the existing artifact_registry_ui flag, dark. Only Step 1 carries a changelog trailer.
• All 34 acceptance criteria are mapped in the Testing strategy, with the client-level ones attributed to the monolith/S02 amendment.
• The plan went through a review pass; its findings are folded in.

Related to gitlab-org&22458