fix(live-usb): nftables — accept DHCP replies (udp sport 67 dport 68)

Bare-metal box ended up with 192.168.10.250 (assigned by secubox-net-
fallback's ARP-probe loop) instead of the real DHCP lease from the
LAN router. Operator confirmed DHCP server is healthy on the LAN
(dev box on same switch got 192.168.1.13 via DHCP without issue).

Root cause: firstboot.sh writes /etc/nftables.conf with policy=drop
on the input chain and no explicit DHCP allowance. The `ct state
established,related accept` rule does NOT cover DHCP because the
client request leaves from 0.0.0.0:68 and the server reply comes back
broadcast (or unicast direct to the offered IP before it's bound).
Neither matches the original 5-tuple → conntrack treats the reply
as a new packet → policy drop → DHCPOFFER lost → networkd times out.
secubox-net-fallback then picks a random gateway from its probe
list and lands the box on the wrong subnet.

Add `udp sport 67 udp dport 68 accept` to the input chain. This
matches DHCPv4 server-to-client replies specifically (port 67/68
are reserved BOOTP/DHCP). DHCPv6 would need a sibling `udp dport
546 accept` rule but is out of scope here.

image/firstboot.sh

@@ -443,6 +443,16 @@ table inet secubox_filter {
         # HTTP/HTTPS (SecuBox UI)
         tcp dport { 80, 443 } accept
 
+        # DHCP client — accept DHCPOFFER / DHCPACK on UDP 68. The
+        # conntrack `established,related` clause above doesn't help
+        # for DHCP because the request goes out from 0.0.0.0:68 and
+        # the reply comes back broadcast (or unicast direct to the
+        # offered IP before it's actually bound), neither of which
+        # match the original 5-tuple. Without this rule networkd's
+        # DHCP times out and secubox-net-fallback's ARP-probe takes
+        # over — operator ends up on a random fallback subnet.
+        udp sport 67 udp dport 68 accept
+
         # WireGuard
         udp dport 51820 accept