dashboard, status API and notifications tell apex domains from hostnames (closes #224)

An apex domain's own records are still saved with the hostnames'
records, under the domain's name, so the port and TLS checks find its
addresses. Notifications about them now start `Domain:`, decided by the
configured domains. The dashboard and /api/v1/status, which read only
the saved state, take a hostname entry whose name also has a domain
entry as that domain's own records: the dashboard shows them in a second
table under Domains, the API in the domain's `recordsByNameserver`, and
neither lists or counts them as hostnames. The startup notification
counts domains and hostnames from the configuration. README says which
of a domain's own records are watched and how their changes are
notified.

Model: opus-5-5

README.md

@@ -81,6 +81,12 @@ notification endpoint set, changes show only on the dashboard; see
       removed gets only the NS change notification. When the lookup of a
       nameserver's addresses fails or finds none, its previous addresses are
       kept and nothing is sent.
+- Also watches the domain's own records as a hostname's are watched (see DNS
+  Hostname Monitoring below): its A, AAAA, CNAME, MX, TXT, SRV, CAA and NS
+  records, stored per nameserver. Their changes are notified as a hostname's
+  are, as a record change, NS query failure, NS recovery, inconsistency or CNAME
+  address change, in a message that starts `Domain:` where a hostname's starts
+  `Hostname:`.
 
 ### DNS Hostname Monitoring (Subdomains)
 
@@ -183,18 +189,18 @@ Supported notification backends:
 All configured endpoints receive every notification. Notification content
 includes:
 
-- **DNS record changes**: Which hostname, which nameserver, what record type,
-  old values, new values.
+- **DNS record changes**: Which hostname or domain, which nameserver, what
+  record type, old values, new values.
 - **DNS NS changes**: Which domain, which nameservers were added/removed.
 - **NS address changes**: Which domain, which nameserver, its old and new
   addresses.
-- **CNAME address changes**: Which hostname, the old and new addresses at the
-  end of its CNAME chain.
+- **CNAME address changes**: Which hostname or domain, the old and new addresses
+  at the end of its CNAME chain.
 - **NS query failures**: Which nameserver failed, error type (timeout, SERVFAIL,
   REFUSED, network error), which hostname/domain affected.
 - **NS recoveries**: Which nameserver recovered, which hostname/domain.
 - **NS inconsistencies**: Which nameservers disagree, what each one returned,
-  which hostname affected.
+  which hostname or domain affected.
 - **Port changes**: Which IP:port, its new state, all associated hostnames.
 - **TLS expiry warnings**: Expiry date and days remaining, CN, associated
   hostname and IP.
@@ -229,7 +235,8 @@ dnswatcher includes an unauthenticated, read-only web dashboard at the root URL
 (`/`). It displays:
 
 - **Summary counts** for monitored domains, hostnames, ports, and certificates.
-- **Domains** with their discovered nameservers.
+- **Domains** with their discovered nameservers, and each domain's own records
+  per nameserver and status, shown as a hostname's are.
 - **Hostnames** with per-nameserver DNS records and status. For a nameserver
   whose query failed, the reason is shown in place of the records.
 - **Ports** with open/closed state and associated hostnames.
@@ -263,7 +270,9 @@ dnswatcher exposes a lightweight HTTP API for operational visibility:
 
 In `/api/v1/status`, each nameserver entry and certificate entry whose `status`
 is `error` also has `error`, the reason, as in the state file (see State File
-Format).
+Format). A domain's own records are in its entry in `domains`, under
+`recordsByNameserver`, in the form a hostname's entry in `hostnames` has them
+under `nameservers`; `hostnames` and `counts.hostnames` hold no domain.
 
 `/metrics` is served only when `DNSWATCHER_METRICS_USERNAME` is set, behind
 Basic Auth. It has the Prometheus Go client's default metrics only (Go runtime,
@@ -455,7 +464,8 @@ resolver: the HTTP client looks up the webhook's or Sentry's host name with it.
 
 The state file (`DATA_DIR/state.json`) contains the complete monitoring
 snapshot. Hostname records are stored **per authoritative nameserver**, not as a
-merged view, to enable inconsistency detection.
+merged view, to enable inconsistency detection. `hostnames` also holds each
+domain's own records, under the domain's name.
 
 ```json
 {