fix(h4): pin enp2s0 as the preferred route so the source address stops floating (2.9)

[swares]

Both interfaces are on the same /24 and both take DHCP, so both installed a default route at metric 100. Equal metric means the kernel picks one and nothing pins the choice -- it had picked enp1s0, so the H4 was sourcing LAN traffic from 192.168.1.156, an address referenced nowhere in this repo. Found in Vault audit logs, where the H4's own requests arrived from an address no document knew about.

This matters beyond tidiness: 2.9's firewall allowlist would have been built from the repo, which says the H4 is .160. It would have worked until a reboot flipped the source address and locked out the machine that runs every playbook, including the one needed to undo the rule -- a failure arriving hours or weeks later, looking unrelated to the change.

Hung off h4_dns_link, the variable that already decides which link is primary, so the resolver link and the preferred-route link are the same link by construction. Two independent knobs would eventually disagree in a way nothing would notice.

route-metric: 200 on the non-primary link. It does not remove .156 or down the link, only which route is preferred -- and nothing is bound to .156 any more, since the unconfigured dnsmasq holding it was disabled in 2.14, found during this same investigation.

Applying stays manual, as this playbook has always been: it writes the override and stops.