Internet exposure checks and response rate limiting

Jarl works out which views are reachable from the internet (match-clients
ending in a catch-all, not private-looking addresses: an internal view of a
global IPv6 prefix is still yours; a server without views: open allow-query
and a non-private listen address), with a per-view override (schema 9), and
checks public ones: rate limiting, open resolver, minimal-any, cache
snooping, open NOTIFY and transfers, version and host name, management
interfaces. Fixes are staged like any change, including rate limiting from
ISC's example in log-only mode with the secondaries exempt, then enforcing.
named logs what rate limiting limits (or would, in log-only mode, where its
counters don't move) as query-errors; Jarl routes those lines to its log
and counts them (rrl breakdown, ratelimited top lists, Prometheus
jarl_ratelimit_logged_total), shown on the new Exposure page.

A change that newly opens a public view up must be confirmed (accept_risk,
--accept-risk, a checkbox on the Changes page; 409 confirm_risk
otherwise). Findings can be acknowledged with a reason and stay visible as
info. GET /exposure, POST /exposure/fix|ack|unack, jarl exposure,
docs/exposure.md.

Also fixes query statistics skipping TSIG-signed queries ("IP#port/key
NAME" in named's log).

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

CHANGELOG.md

@@ -8,12 +8,21 @@ All notable changes to Jarl are documented here. The format follows
 
 ### Upgrading from 0.4
 
+- New exposure warnings (docs/exposure.md) appear for views reachable from
+  the internet, e.g. "no rate-limit" or "version visible" on an external
+  view: fix them from the Exposure page, or acknowledge them. A change
+  that newly opens a public view up (an open resolver, say) now needs
+  `--accept-risk`, or the checkbox on the Changes page.
+
 - Once you use address ranges, the database can't go back to 0.4: its
   parser doesn't know them. Remove the ranges first if you need to
   downgrade.
 
 ### Fixed
 
+- Query statistics skipped every query signed with a TSIG key (named
+  writes "/key NAME" after the client's port), such as queries with a
+  view's key: they are counted now.
 - A changeset with a staged record delete could not be applied after that
   record was deleted elsewhere (e.g. with the CLI), and it was hard to see
   which operation to remove: the error only said "record 832 does not
@@ -25,6 +34,24 @@ All notable changes to Jarl are documented here. The format follows
 
 ### Added
 
+- Internet exposure ([docs/exposure.md](docs/exposure.md)): Jarl works out
+  which views are reachable from the internet (match-clients ending in a
+  catch-all; for a server without views, open allow-query and a
+  non-private listen address), with a per-view override, and checks them:
+  response rate limiting, open resolvers, ANY answers (minimal-any), cache
+  snooping, open NOTIFY and zone transfers, BIND version and host name,
+  management interfaces. Fixes are staged like any change, including
+  response rate limiting from ISC's example in log-only mode, with your
+  secondaries exempt, and a later "start enforcing". With statistics on,
+  Jarl reads named's rate limiting log lines and shows what was (or would
+  have been) limited: counts, client networks and names (Exposure page,
+  `jarl stats breakdown rrl`, top lists `ratelimited`, Prometheus
+  `jarl_ratelimit_logged_total`). A change that newly opens a public view
+  up must be confirmed (checkbox on the Changes page, `--accept-risk`, API
+  `accept_risk`; 409 `confirm_risk` otherwise). Findings can be
+  acknowledged with a reason: they stay visible as info, with who, when
+  and why. Exposure page and dashboard card in the web UI, `jarl
+  exposure` (fix, ack, unack), `GET /exposure`.
 - `jarl changeset show`, `diff`, `apply`, `discard` and `remove` take the
   changeset from `-C` or `JARL_CHANGESET` when no ID is given
   (`jarl changeset apply`). A changeset from `JARL_CHANGESET` is now