Add a Zones console: create and manage local zones, records and delegations

The console could not see local zones at all. `blocklist.local_zones` compiled
a store that nothing read back: there was no API for a zone, its records, its
delegations or the file a record came from, and no way to change one without
editing YAML and reloading. The Domains page is the blocklist's inline rules,
not local data, so nothing in the console covered the half of the server that
answers authoritatively from disk. There is now a Zones page and the endpoints
behind it: `GET /api/zones`, `POST`/`PUT`/`DELETE /api/zones/records`,
`POST`/`DELETE /api/zones/delegations` and `DELETE /api/zones?zone=`.

**The console owns one directory and nothing else.** `blocklist.managed_zones`
holds one `<apex>.zone` per zone, with that zone's SOA, apex NS set and the
records added there, and it is compiled by the same `localzone.Load` as the
operator's files — so a record added from the console is served on the next
query, with no reload and no restart. Files in `blocklist.local_zones` are
listed and shown read-only and are never rewritten; the key defaults to empty,
so a deployment that never sets it gets a zone browser and no zone writes.
Which file a record came from is now part of the store (`zone.files`, keyed by
the index the store already uses), so the snapshot can say "console" or "your
file" per record; the query path does not read it.

**The writer proves its own output.** A record is validated by the project's own
master-file parser, so `www` means `www.<zone>` and a bare CNAME target is
completed exactly as it would be in a zone file; the file is rendered, and the
rendering is re-parsed and compared with the records it meant to write before
the file is renamed into place. A writer bug that dropped a record would
otherwise present as a zone that silently stopped answering. A zone that cannot
answer is refused rather than created: no SOA means no NXDOMAIN or NODATA
authority, and no apex NS means nothing is delegated and no server is named. The
SOA's primary follows the apex NS set — a zone whose SOA names a server outside
its own NS set hands out a referral no resolver can follow — and the serial
moves on every write.

**A delegation takes the names under it, so a record below a cut is refused.**
The store answers those names as delegated without reading the zone file, which
would make the record data that looks alive and never answers. `DELETE
/api/zones?zone=` exists for the same reason from the other side: a zone the
console created is a real zone, so it says NXDOMAIN for what it does not hold,
and deleting a record is not what gives a name back to upstream. It is
refused for a zone that also has records outside the managed directory, because
removing that file would remove none of the zone.

**Two bugs the work turned up.** `engine.applyConfig` published local-record
metrics only when `blocklist.local_zones` was non-empty, so a zone the console
created was served but never counted; the gate is now the store's own record
count. And the record-value renderer fell back to `RR.String()` for every type
it did not know, which is the whole line rather than the RDATA — it wrote a
name and a TTL into the value column for DHCID, LOC, SSHFP and SVCB, and would
have fed that back as a record value on the next edit.

Every write recompiles the store and flushes the cache. Which names changed is
not knowable from the API, and a cached upstream answer for a name the zone now
answers is simply wrong, so the flush is blunt on purpose.

The wire shapes are type aliases in `internal/api` rather than copies, so there
is one set of json tags, and `TestZoneEndpointKeySets` pins the key set at every
level with a record and a delegation actually present — an empty list only
proves the envelope. `TestZoneWritesNeedAManagedDirectory` pins the read-only
default, and `TestZoneConsoleRoundTrip` walks the whole thing: a record added
through the API is answered authoritatively on the next query, a cut stops the
parent answering below it, and deleting the zone hands the name back.

Verified against a running instance built from this tree: records and
wildcards answer with `aa`, relative names are qualified, a record below a cut
is refused with a message that says why, and the file on disk is a zone file
an operator can read. The console page is typechecked and built; the browser was
not available in this round, so it has not been looked at.

README.md

@@ -248,6 +248,7 @@ file.
 | `blocklist.response_ttl` | duration | `60s` | TTL of synthesised answers |
 | `blocklist.redirect_name` | name | — | required when `default_action: redirect` |
 | `blocklist.local_zones` | list of globs | empty | RPZ policy zones and/or local authoritative data, read from master files |
+| `blocklist.managed_zones` | path | empty | the only directory the admin console may **write** zone data into, one `<apex>.zone` per zone; empty keeps the console's Zones page read-only |
 | `blocklist.block_entries` / `allow_entries` | list of lines | empty | inline rules, compiled as `inline:block` / `inline:allow` and applied before every list |
 | `blocklist.parallelism` | int | `4` | **unused** — compilation is single-threaded |
 | `blocklist.lists[].name` | string | — | required, unique |
@@ -430,6 +431,14 @@ records mean and where they are matched:
 one-label and deeper wildcards, SRV, TXT). `deploy/zones/local.rpz.zone.example`
 is a policy zone.
 
+**Two zone pages, two ownership models.** **Local zones** edits the RFC 1035
+master files themselves (in Kubernetes, one file per zone in the
+`fancy-dns-zones` ConfigMap; standalone, the files named by
+`blocklist.local_zones`). **Zones** is the record-level view and the only one
+that writes a directory of its own, `blocklist.managed_zones`. They are
+separate on purpose: the first edits what you wrote, the second writes what it
+owns. Neither rewrites the other's files.
+
 **Edit zones in the console.** Open **Local zones** to create a zone or edit its
 RFC 1035 master-file records. In Kubernetes, the editor stores each file in the
 `fancy-dns-zones` ConfigMap; both replicas watch the projected files and reload
@@ -438,6 +447,35 @@ saving. The pod's service account can read and patch only this ConfigMap. The
 ConfigMap's `data` is intentionally left out of the GitOps manifest so console
 edits persist across reconciliation. For a standalone install, manage zone
 files on disk and reload the configuration.
+**Zones the console writes.** `blocklist.managed_zones` names a directory the
+admin console owns: one `<apex>.zone` per zone, holding the SOA, the apex NS
+set and whatever records were added there. It is a zone source like any other —
+`localzone.Load` compiles it alongside `local_zones` — so a record added from
+the console is served on the next query, with no reload and no restart. The
+master files in `local_zones` are never rewritten: they are listed in the
+console's Zones page and shown as read-only. Without `managed_zones` the page
+is a browser and nothing else.
+
+Four rules the writer holds to, all of them because the alternative is a zone
+that silently stops answering:
+
+* A record line is validated by the project's own master-file parser, so an RDATA
+  name written without a trailing dot means the same thing here as in a zone
+  file, and the value the API echoes is the value the file holds.
+* What the writer renders is re-parsed and compared with what it meant to write
+  before anything touches the disk. A round-trip that loses a record is a
+  writer bug, caught there rather than by an operator noticing an empty zone.
+* A zone needs an SOA (or it cannot answer NXDOMAIN/NODATA) and an NS record at
+  the apex (or it delegates nothing and has no server to name), so a brand new
+  zone is started with one of the two. The SOA's primary follows the apex NS
+  set, and the serial moves on every write.
+* A record at or below a delegation is refused: the store answers those names as
+  delegated and never looks at the zone file, so it would be data that looks
+  alive and never answers.
+
+A record is written by rewriting the whole file, so a file under
+`managed_zones` is the console's to own; hand-maintained data belongs in
+`local_zones`. Each file says so in its header.
 
 ## Blocklists
 
@@ -506,6 +544,13 @@ is on.
 | GET | `/api/domains/check?name=…` | — | explain how a name would be treated (the fastest "why isn't this blocked" tool) |
 | POST | `/api/domains` | yes | add an inline rule |
 | DELETE | `/api/domains/{name…}?action=&list=` | yes | remove a rule |
+| GET | `/api/zones` | — | every local zone with its records, delegations, source files, the managed directory, whether it is writable, the writable record types, and why the store is stale (`error`) |
+| POST | `/api/zones/records` | yes | add a record (`{"zone","name","type","ttl","value"}`; a name without a trailing dot is relative to the zone) |
+| PUT | `/api/zones/records` | yes | replace the whole RRset of one name and type |
+| DELETE | `/api/zones/records?zone=&name=&type=&value=` | yes | remove one record, or the RRset when `value` is empty |
+| POST | `/api/zones/delegations` | yes | delegate a name to other servers (`{"zone","name","targets":[…],"ttl"}`); the delegation's targets become the apex NS set of a zone that has none |
+| DELETE | `/api/zones/delegations?zone=&name=` | yes | remove a cut |
+| DELETE | `/api/zones?zone=` | yes | delete a zone the console owns, so its names go back to whatever answered for them before; refused for a zone with records outside the managed directory |
 | GET | `/api/clients` | — | ACL groups and the default policy |
 | PUT | `/api/clients` | yes | replace the ACL (`{"groups":[…],"default_policy":…}`); validates, writes the file, swaps, broadcasts |
 | GET | `/api/upstreams` | — | pool state, health, latency, breaker |