fix(deploy): home's tunnel rules loaded by systemd, outside wg-quick's AppArmor profile (ADR 0039, D9)

Ubuntu 26.04 confines wg-quick in an AppArmor profile whose nft sub-profile
may read nothing in /etc/wireguard, so the tunnel failed to come up at home.
The unit's drop-in (wg-quick-halkyon.conf, before-docker.conf before) loads
the rules before the interface exists and deletes them after it is gone, so
the tunnel never runs without them. ramiel, on 24.04, keeps PostUp.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: Tizian 「ティツィアーン」 <raisondetredev@pm.me>

deploy/host/wg-halkyon.conf

@@ -1,14 +1,12 @@
 # Home's end of the tunnel through which ramiel publishes halkyon.li (ADR 0039, D8), as
 # /etc/wireguard/wg-halkyon.conf on the instance's host at home (root, 0600), brought
-# up by wg-quick@wg-halkyon before Docker (wg-quick-before-docker.conf). Its private key
-# is a file of its own beside it, never here. Setting it up: host/README.md.
+# up by wg-quick@wg-halkyon before Docker, its rules loaded around it (both
+# wg-quick-halkyon.conf). Its private key is a file of its own beside it, never here.
+# Setting it up: host/README.md.
 
 [Interface]
 Address = 10.61.97.2/30
 PostUp = wg set %i private-key /etc/wireguard/wg-halkyon.key
-# From ramiel only Caddy's 443 and sshd's 22, nothing towards it (D9, D17).
-PostUp = nft -f /etc/wireguard/wg-halkyon.nft
-PreDown = nft delete table inet halkyon_tunnel
 
 # ramiel, dialled by its address: home opens nothing on the FRITZ!Box, and a new home
 # address needs no change anywhere. The keepalive keeps the way back open through the