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>

docs/adr/0039-halkyon-li-at-home.md

@@ -94,8 +94,11 @@
   balthasar dials out with `PersistentKeepalive = 25`, so the FRITZ!Box opens nothing
   and a new home address needs no change. Each side's `AllowedIPs` is the other's
   address alone. The keys stay in `/etc/wireguard/` (root, 0600) and in Proton Pass.
-- **D9 What the tunnel may carry**, by rules `PostUp` sets and `PreDown` removes, in
-  chains of their own as ADR 0032's:
+- **D9 What the tunnel may carry**, in chains of their own as ADR 0032's, living as long
+  as the tunnel: on ramiel set by wg-quick's `PostUp` and removed by its `PreDown`; at
+  home loaded by systemd before the interface exists and deleted after it is gone
+  (`ExecStartPre`, `ExecStopPost`), as Ubuntu 26.04's AppArmor profile for wg-quick lets
+  its `nft` read nothing in `/etc/wireguard` (found 8 Nov 2026):
   - on ramiel: HAProxy's connections to `10.61.97.2:443`, nothing else; nothing new
     from the tunnel into ramiel (so a taken-over balthasar can't reach ramiel's sshd or
     Forgejo);