Report an allocated IPv4 address that is not on the host

IPv6 works end to end between two machines; IPv4 silently did not, and the
agent said nothing useful about why.

Allocation moved the address from something derivable before startup to
something agreed at run time, so an interface configured by an earlier
`tun-setup` carries a different address than the one allocated. The kernel
then sends packets with that stale source and every peer drops them as not
belonging to us — correct behaviour, invisible cause. Meanwhile pings to
our own allocated address fall into the tunnel and land in the "nobody
owns this" counter.

The agent now checks whether its allocated address is assigned anywhere on
the host — by binding a UDP socket to it, which needs no privileges and no
platform code — and reports the exact `ip address add` command until it
is, mentioning that another address of the range has to go.

`tun-setup` no longer prints a derived IPv4 address, because that number
is now wrong by construction. It says the agent will print the real one.

The unroutable counter keeps one destination as a sample, in status output
too. A bare count says something is wrong; the address says what.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

README.md

@@ -145,6 +145,13 @@ No vote is involved — see
 [docs/wireguard.md](docs/wireguard.md#ipv4-allocated-signed-and-kept) and
 [docs/sync-model.md](docs/sync-model.md).
 
+Because the address is allocated at run time rather than derived, it is not
+known until the agent has started and agreed with its peers, so
+`tsunagi tun-setup` cannot print it in advance. The agent prints the exact
+`ip address add` command once it has one, and keeps saying so until the
+address is actually on an interface — without it, packets leave with the
+wrong source address and every peer drops them.
+
 ## Running unprivileged
 
 The agent does not need to run as root. Creating a network interface and