Boot fallback, flowtable devices that come and go, healthz, renames

The boot unit fails closed: if ruleset.nft doesn't load, it loads
ruleset-fallback.nft (render.Fallback), saved beside it from the same
configuration: nothing new in from external zones, established, the
ICMPv6 IPv6 needs and DHCPv6 replies let in, the inside left alone and
masqueraded, and the unit marked failed with a critical message.
housecarld replaces it when it applies; status, the dashboard and
/healthz say while it is in force. no_external_zone now also says the
fallback closes everything without an external zone.

The boot ruleset has no flowtable: nftables on Debian 13's kernel
refuses one naming a device that doesn't exist yet (ppp0 before PPPoE),
and with it the whole file. internal/linkwatch listens to rtnetlink link
messages; housecarld applies again when a flowtable device appears or
comes back as a new interface (by ifindex), under the engine's lock.
docs/flowtable.md: what it does, when to use it and when not, how.

GET /healthz reports firewall (applied, unconfigured, fallback,
missing), changes on probation and the machine's warnings, with 503
unless in force, read at most every five seconds.

Renaming a zone, set or service changes what names it in the same
change (one history entry, one undo); dynamic sets keep their names.
The importer keeps a chain's head in order: once a would-be built-in
stays a rule, the ones after it do too, so the maintainer's ICMPv6
accepts stay behind the invalid drop as written. hc settings set
--flowtable none empties the list.

make test (nft 1.1.3) and make e2e (242 checks, with VLAN
sub-interfaces, the fallback and the flowtable) pass.

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

docs/design.md

@@ -139,6 +139,19 @@ firewall is up even if housecarld can't start. An unconfirmed ruleset is
 never saved there: a reboot during probation brings back the last
 confirmed one.
 
+It fails closed. A fallback saved beside it (`ruleset-fallback.nft`,
+`render.Fallback`) is loaded if it doesn't: no sets, no flowtable,
+interfaces by name only, so there is little in it to fail. It keeps
+anything new from the external zones out and lets the inside work,
+which is as far as a ruleset can go without knowing the rules; a
+fallback that let everything in would leave a router open on the
+internet, and one that let nothing in would lock out the person who has
+to fix it. The boot ruleset has no flowtable either: nftables refuses a
+flowtable naming a device that doesn't exist yet (on Debian 13's
+kernel), and before the network is up, `ppp0` doesn't. housecarld
+watches the kernel's link messages (internal/linkwatch) and applies
+again when a flowtable device appears, or comes back as a new interface.
+
 ## The drop log
 
 Rules with logging on, and the policies (Settings), send packets to