apply-network: reload networkd after each netplan apply; post-check flags a networkd/NM double claim

Live R5C run: after the Armbian catch-all .network was removed, networkd kept its
in-memory claim on the uplink port (two addresses, extra proto dhcp default route)
until `networkctl reload`. The helper now reloads networkd after the forward apply
and after the rollback re-apply (not fatal, not gating; logs the port state and a
"networkd still manages" note on the forward path), the AN_* time budget includes
it, and --post-check warns when the netplan matches but networkd still lists the
uplink port configured/configuring.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KqhjP7nud5gdBg25zCiRk9

README.md

@@ -19,7 +19,7 @@ host file matches the hostname — and the refusal to replace a WAN netplan that
 helper installs the netplan, gates on uplink health and rolls back automatically on failure. Its log
 is `/var/log/vanlink-apply-network.log` and its status line is in
 `/var/lib/vanlink/apply-network.status` (`ok|running|rolled-back|rollback-failed`). `./deploy.sh --wan-plan`
-shows, read-only, what the provisioning would do. `--post-check` reports the last apply status. Until a host's WAN netplan is applied, the routine deploy also keeps
+shows, read-only, what the provisioning would do. `--post-check` reports the last apply status. The apply also reloads networkd (`networkctl reload`) so it drops its stale claim on the uplink port, and `--post-check` warns when networkd and NetworkManager both still claim that port. Until a host's WAN netplan is applied, the routine deploy also keeps
 NetworkManager off the uplink with `/etc/NetworkManager/conf.d/zz-van-wan-pending.conf` (only while the netplan is
 *missing*; `--wan-plan` shows it) — the apply removes it.