Remove the ConfigMap, RPZ and managed-directory editors the cluster objects replace

Zones, address redirects, inline rules, lists and groups are cluster objects now
(see the previous commits and deploy/MIGRATION.md), so the mechanisms that held
them are gone:

* internal/kubezones and the resolver's service-account access to a ConfigMap,
  the address-overrides read/write path and its poller, the zone-file poller and
  the Local zones editor with its /api/local-zones routes.
* localzone.Managed, the directory of console-written master files, and the
  blocklist.managed_zones key. The resolver now writes no zone data at all; its
  zone hooks only list. The shared half of that file (the record validator, the
  renderer and the round-trip check) stays as zonestate.go, because DNSZone
  rendering is built on it. Its tests are ported to RenderZone, which keeps the
  coverage of every editable record type, wildcards, relative owners, the
  SOA/NS rule and the delegation rule.
* Tests of the removed write paths: the contract test now builds its zone from a
  DNSZone, and a new test pins that every zone write route on the resolver is
  refused and changes nothing.

Standalone installs keep editing master files on disk and SIGHUP, and the
YAML-backed domain, client, upstream and settings editors, which have not moved.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>

deploy/MIGRATION.md

@@ -0,0 +1,89 @@
+# Moving a ConfigMap deployment to cluster objects
+
+Until now the console edited zones and address redirects by writing two
+ConfigMaps (`fancy-dns-zones`, `fancy-dns-rpz`) through the resolver's service
+account, and the domains page rewrote the config file. Those mechanisms are gone.
+Everything the console edits is now an object:
+
+| Was | Is |
+|---|---|
+| `zone--<apex>.zone` keys in the `fancy-dns-zones` ConfigMap | `DNSZone` |
+| `address-overrides.rpz` in the `fancy-dns-rpz` ConfigMap | `AddressOverride` (one per name) |
+| `blocklist.allow_entries` / `block_entries` | `DomainRule` (`inline-allow`, `inline-block`) |
+| `blocklist.lists` with a URL | `BlockList` |
+| `acl.groups` | `ClientGroup` |
+| listeners, upstreams, cache, `default_policy` | still the resolver's YAML |
+
+The old resolver does not read the objects and the new one does not read the
+ConfigMaps, so the order below matters: **create the objects while the old
+resolver is still serving, switch, then delete the ConfigMaps.** Nothing here
+deletes anything until the last step.
+
+## 1. Install the definitions and permissions
+
+```sh
+kubectl apply -f deploy/k8s/crds/crds.yaml
+kubectl apply -k deploy/k8s/crds            # lets the resolver's service account read the objects
+kubectl apply -f deploy/k8s/console/console.yaml   # the console, which writes them (create its two Secrets first)
+```
+
+## 2. Convert what you have
+
+The command reads the two ConfigMaps from the cluster and, if you give it the
+resolver's `config.yaml`, its URL lists, inline entries and ACL groups. By
+default it only **prints** manifests.
+
+```sh
+kubectl -n dns get cm fancy-dns-config -o jsonpath='{.data.config\.yaml}' > /tmp/config.yaml
+
+FANCYDNS_API_KEY=unused \
+fancy-dns-console migrate -kube-namespace dns -config /tmp/config.yaml > migrated.yaml
+```
+
+(`FANCYDNS_API_KEY=unused`: the config expands `${VAR}` references and refuses an
+unset one; the value is not used.) Read `migrated.yaml`, and read what the
+command printed on stderr:
+
+* `converted:` lines say what became an object and what to remove from the config.
+* `NOT converted:` lines are things it could not represent faithfully (a zone
+  with a record type the console does not write, a list that is a file on the
+  pod, a name that is not a legal object name). Those stay where they are.
+
+Commit `migrated.yaml` if you manage the cluster with GitOps, or apply it:
+
+```sh
+fancy-dns-console migrate -kube-namespace dns -config /tmp/config.yaml -apply
+```
+
+It is safe to run again: objects are created or updated, never duplicated.
+
+## 3. Switch the resolver
+
+* Start it with `-kube` (the StatefulSet in `deploy/k8s/10-deployment.yaml` does).
+* In `config.yaml`, remove what moved: the `edge-router-x-address-overrides` list
+  and any other list you converted, `acl.groups`, the inline entries,
+  `blocklist.managed_zones` and the `fancy-dns-zones` glob in `local_zones`.
+* Roll it out.
+
+## 4. Check before you delete anything
+
+```sh
+kubectl -n dns get dnszones,addressoverrides,clientgroups,blocklists,domainrules
+curl -s https://<console>/api/status      # components.degraded must not mention kubernetes
+dig @<resolver> <a name from each zone and override>
+```
+
+A rejected object is not a silent failure: it is logged by the resolver, the
+node reports "kubernetes: objects rejected" as degraded, and an object that was
+valid before keeps its last good version.
+
+## 5. Delete the old ConfigMaps
+
+Only now:
+
+```sh
+kubectl -n dns delete cm fancy-dns-zones fancy-dns-rpz
+```
+
+If your GitOps tool prunes, remove them from the repository **after** step 4, not
+before: they hold the only copy of the data until the objects exist.