fix(wireguard): hold /0 allowedIPs to the overlap guard

The tunnel overlap guard treated every /0 allowedIPs entry as claiming
no address, while the entry was stored with its host bits and the
consumers read them back: the AmneziaWG port forwarder resolves a peer's
target from them and the device routes the /0 by longest prefix. An
entry such as 10.8.1.2/0 therefore passed next to another client's
10.8.1.2/32, and forwarded ports reached that client's device.

A written entry now counts with its whole range, so a /0 collides with
every held address of its family. On the stored side only a literal
0.0.0.0/0 or ::/0 default route keeps nobody out, and a /0 with host
bits claims that host. Editing a legacy peer that echoes its stored
default route still works.

docs/content/docs/en/reference/api/clients.mdx

@@ -609,9 +609,11 @@ _openapi:
           different client of that same inbound holds, or `... used by a client
           on <inbound>` when the holder sits on another WireGuard or AmneziaWG
           inbound. Ranges are compared, not strings, so `10.0.0.9/24` collides
-          with `10.0.0.5/32`; a `0.0.0.0/0` or `::/0` default route claims no
-          address. Allocation likewise skips every address inside a prefix
-          another client holds. The same validation runs on POST
+          with `10.0.0.5/32`; a `/0` entry collides with every address of its
+          family another client holds, and only a `0.0.0.0/0` or `::/0` default
+          route that is already stored (legacy peers) keeps nobody out.
+          Allocation likewise skips every address inside a prefix another client
+          holds. The same validation runs on POST
           /panel/api/clients/{email}/attach, where a client that already carries
           an address brings it along.