feat: register DNS in the service catalog

Add a service-catalog Kustomize component that publishes the DNS
Service resource (services.miloapis.com/v1alpha1) into the Milo
catalog. Establishes identity (serviceName dns.networking.miloapis.com),
display metadata, and producer owner, in phase Published.

This is Phase 1 of #44 (service registration). The ServiceConfiguration
that declares DNS metering is left as a stubbed slot for Phase 2.

The bundle is deployed into the services-operator namespace by Flux
from infra, not by the operator overlays.

Author: kevwilliams

config/components/service-catalog/README.md

@@ -0,0 +1,62 @@
+# Service catalog
+
+DNS's catalog identifiers — everything the services-operator and
+downstream Milo controllers need in order to recognise DNS as a
+billable service.
+
+Concrete `Service` + `ServiceConfiguration` registrations are
+deployable artefacts that the producing service publishes as part of
+its own deployment process, so they live here in `dns-operator` rather
+than in the [`datum-cloud/services`](https://github.com/datum-cloud/services)
+API-surface repo.
+
+## Contents
+
+| Kind                   | Name                          | What it declares                                                            |
+| ---------------------- | ----------------------------- | --------------------------------------------------------------------------- |
+| `Service`              | `dns-networking-miloapis-com` | `serviceName`, display metadata, producer owner.                            |
+| `ServiceConfiguration` | `dns-networking-miloapis-com` | DNS MonitoredResourceTypes, metrics, and billing routing. _(Phase 2 — TBD)_ |
+
+Ships in `phase: Published`.
+
+## Identity
+
+- **`serviceName`: `dns.networking.miloapis.com`** — the canonical
+  reverse-DNS identifier, matching the DNS API group. It is the
+  cross-system join key used by `MeterDefinition`,
+  `MonitoredResourceType`, billing exports, and the portal. Immutable
+  once Published.
+- **`metadata.name`: `dns-networking-miloapis-com`** — the Kubernetes
+  slug (serviceName with dots replaced by dashes).
+
+## Why a `ServiceConfiguration` instead of raw `MeterDefinition`s
+
+The canonical producer-facing document for billing is
+`services.miloapis.com/v1alpha1.ServiceConfiguration` — see
+[`billing/docs/emitting-usage.md`](https://github.com/datum-cloud/billing/blob/main/docs/emitting-usage.md).
+A producer authors _one_ document; the services-operator fans it out
+into `billing.miloapis.com/MeterDefinition` and `MonitoredResourceType`
+objects stamped `app.kubernetes.io/managed-by: services-operator`.
+Producers must not author those downstream CRDs directly — edit the
+`ServiceConfiguration` and let the fan-out catch up.
+
+The DNS `ServiceConfiguration` is tracked as Phase 2 of the catalog
+registration (metering): query volume, hosted zones, and record-set
+inventory. See the
+[catalog registration issue](https://github.com/datum-cloud/dns-operator/issues/44).
+
+## Immutability after `Published`
+
+- On `Service`: `spec.serviceName` is immutable. Display name and
+  description may still evolve.
+- On `ServiceConfiguration` (once added): `spec.metrics[].name`,
+  `.kind`, `.unit` and `spec.monitoredResourceTypes[].type`, `.gvk` are
+  immutable. Renames or unit changes ship as a new metric name (e.g.
+  `.../v2`).
+
+## Deployment
+
+This bundle is **not** applied by the operator deployment overlays
+(`config/agent`, `config/overlays/replicator`). It is deployed into the
+services-operator's namespace by Flux from the infra repo, the same way
+other services publish their catalog entries.

config/components/service-catalog/kustomization.yaml

@@ -0,0 +1,30 @@
+# SPDX-License-Identifier: AGPL-3.0-only
+
+apiVersion: kustomize.config.k8s.io/v1beta1
+kind: Kustomization
+
+# Service catalog registration for the Datum Cloud DNS service.
+#
+# Authors the cluster-scoped documents the services-operator uses to
+# reason about DNS:
+#
+#   1. The `Service` itself (`dns-networking-miloapis-com`), which carries
+#      identity (`serviceName`), display metadata, and producer owner.
+#      (Phase 1 — service registration.)
+#   2. A single `ServiceConfiguration` (same name, different Kind) that
+#      will declare the DNS MonitoredResourceTypes, metrics, and billing
+#      routing. (Phase 2 — metering; not yet authored.)
+#
+# Per billing's `emitting-usage.md`, the `ServiceConfiguration` is the
+# *only* document a producer authors for billing: the services-operator
+# fans it out into `billing.miloapis.com/MeterDefinition` and
+# `MonitoredResourceType` objects stamped
+# `app.kubernetes.io/managed-by: services-operator`. Do not author those
+# directly.
+#
+# This bundle is NOT applied by the operator deployment overlays. It is
+# deployed into the services-operator's namespace by Flux from the infra
+# repo, the same way other services publish their catalog entries.
+resources:
+  - services_v1alpha1_service_dns.yaml
+  # - services_v1alpha1_serviceconfiguration_dns.yaml  # added in Phase 2

config/components/service-catalog/services_v1alpha1_service_dns.yaml

@@ -0,0 +1,22 @@
+# SPDX-License-Identifier: AGPL-3.0-only
+
+apiVersion: services.miloapis.com/v1alpha1
+kind: Service
+metadata:
+  labels:
+    app.kubernetes.io/name: dns-operator
+    app.kubernetes.io/managed-by: kustomize
+  name: dns-networking-miloapis-com
+spec:
+  serviceName: dns.networking.miloapis.com
+  phase: Published
+  displayName: DNS
+  description: |
+    Managed authoritative DNS for Datum Cloud. Model zones, record sets,
+    and zone classes as Kubernetes resources and have them programmed
+    into a DNS backend (PowerDNS). Billed via the
+    dns.networking.miloapis.com meter family declared by this service's
+    ServiceConfiguration.
+  owner:
+    producerProjectRef:
+      name: datum-cloud