Provisioning service and cached handle/status resolution (monolith/S10 Steps 2-3)

Part of epic &22458 (Activation and deactivation, monolith/S10). Covers plan Steps 2 and 3.

Scope

Step 2: Provisioning service with the derived billing anchor

• ArtifactRegistry::ProvisionNamespaceService returning ServiceResponse: validate the handle, derive the owner and billing anchors (refuse when the organization has zero or several top-level groups), log the request, call AR, log the returned UUID, write the mapping row on 201/200 replay, and rescue the uniqueness violation into a resolution of the existing row.
• ArtifactRegistry::HandleValidator: the contract's rules transcribed once (length 3-63, lowercase ASCII, digits, non-consecutive hyphens, alphanumeric first/last).
• ArtifactRegistry::Logger (Gitlab::JsonLogger subclass) writing before the row write and again on failure.
• Depends on Step 1 and the S02 amendment's #provision_namespace.

Step 3: Handle and status resolution with caching

• Single AR entry point on NamespaceMapping#registry: resolve handle, derived status, and creation time from the UUID; cache the triple (5 min) and a typed failure marker (1 min) under one Rails.cache.fetch; make no call without a mapping row; #expire_registry_cache for the mutations.
• Memoized per-request service-authenticated client on the organization model (not S03's user-bound CachesClient).
• Depends on Step 1 and the S02 amendment's #namespace.

Both dark behind artifact_registry_ui.