Docs: README --force semantics; spec amendments for the pending conf, preflight and byte-identical netplan

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

README.md

@@ -14,11 +14,14 @@ Hosts with `ENABLE_NM_WAN=1` (`hosts/*.conf`) run their uplinks (Starlink, Wi-Fi
 NetworkManager. `deploy.sh` installs the packages and the cellular NM connection
 (`CELLULAR_CONN_NAME`/`CELLULAR_APN`), but a routine deploy never touches `/etc/netplan/*` or flaps
 an uplink; it only warns when the WAN netplan is missing or differs. Apply it with
-`sudo ./deploy.sh --apply-network` (add `--force` to override a blocking status): a detached
+`sudo ./deploy.sh --apply-network` (`--force` also overrides a blocking status, the preflight — port present,
+host file matches the hostname — and the refusal to replace a WAN netplan that differs): a detached
 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.
+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
+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.
 
 Live WAN state: `cat /run/van-failover/state.json` lists each WAN with `device`, `connection`,
 `present` (device and connection both resolved), `up`, `healthy`, `active` (holds the best default