…#10445)

## Root Cause

On PRs where testnet allocation is pinned to the local DC (#10436),
`//rs/tests/networking:canister_http_socks_test` fails with every
outcall attempt erroring as:

```
direct connect ... ConnectionRefused
and connect through socks "... Connector(ConnectError(\"tcp connect error\", ... ConnectionRefused))"
```

The *direct* refusal is intentional (the test injects an egress-reject
rule for httpbin first). The real failure is the SOCKS leg: the nested
`Connector(ConnectError(...))` means the TCP connection **to the SOCKS
proxy itself** — API boundary node port 1080 — was refused, on every
attempt for the entire run, on **both** API BNs.

A "connection refused" (RST) pins this down precisely:

- The API BN firewall uses `policy drop` with an explicit `accept` for
node IPs on port 1080, so a firewall problem would cause *timeouts*, not
RSTs.
- An RST means the BN was up, its global IPv6 was configured in the
kernel, the packet passed the firewall — and **nothing was listening on
:1080**.

`danted.conf` configured the listener as:

```
internal: enp1s0 port = 1080
```

Dante resolves an interface name to its addresses **once at startup**
and never re-binds. GuestOS receives its global IPv6 via SLAAC. If
`danted.service` starts while `enp1s0` only has its link-local address
(router advertisement not yet processed), danted binds the link-local
scope only and the global `[...]:1080` endpoint stays closed forever —
`Restart=always` never kicks in because danted keeps running happily.

This is confirmed directly by the journald logs of one of the failing
API BNs:

```
13:57:58.543  enp1s0: Gained IPv6LL
13:57:58.547  Finished systemd-networkd-wait-online.service - Wait for Network to be Online.
13:57:58.549  Reached target network-online.target - Network is Online.
13:57:58.553  Started danted.service - SOCKS (v4 and v5) proxy daemon (danted).
...
13:57:58.637  danted[1030]: info: Dante/server[1/1] v1.4.4 running
```

`systemd-networkd-wait-online` completed 4 ms after the interface gained
only its **link-local** address — `network-online.target` does not
guarantee a global SLAAC address — and danted started 6 ms later,
binding the link-local address only.

This race got amplified by DC pinning: in the failing run all nine VMs
of the testnet (5 replicas, 2 API BNs, 2 UVMs) were packed onto a single
host, slowing down boot and RA/SLAAC delivery enough to hit the race on
both API BNs at once. The bug is pre-existing on `master`; the DC
pinning only widened the window. The same fragility was previously
patched around in #4658 (`PartOf=systemd-networkd.service` to restart
danted when networkd restarts).

## Fix

Bind the wildcard address instead of an interface name:

```
internal: :: port = 1080
```

A wildcard bind does not depend on address assignment timing —
connections to the global address succeed as soon as the address exists.
Access to the SOCKS proxy remains restricted through the firewall, which
only whitelists node IPs on port 1080 (the config already noted "Allow
everyone - this is already restricted through the firewall").

`external: enp1s0` (the outgoing side) is unchanged.

## Verification

- `bazel test --runs_per_test=3
//rs/tests/networking:canister_http_socks_test` passes 3/3 (avg 186 s)
on the DC-pinned branch that previously reproduced the failure.