RU DPI/TSPU blocks protocol on v1.7.12 ("None of the endpoints are available"); v1.8.1-nightly.1 works; no auto-reconnect on silent endpoint loss

### Please answer the following question for yourself before submitting an issue

- [x] I checked to make sure that this issue has not already been filed

### AdGuard VPN CLI version

1.7.12 (release) and 1.8.1-nightly.1

### Environment

- OS: Debian 12 (bookworm), kernel 6.1.0-26-amd64
- Architecture: x86-64
- Usage: Linux gateway/NAT box — TUN mode, `config set-tun-routing-mode NONE`, `set-change-system-dns off`, `set-bound-if-override enp6s18`, `connect --no-fork -y -l "..."` under systemd, Restart=on-failure
- Locations: US (New York / Seattle)
- Network path: Russia, ISP with TSPU (DPI) equipment

### Issue Details

Steps to reproduce:

1. Run v1.7.12 connected directly through a Russian ISP (TSPU present), New York location, TUN mode.
2. During the morning of 2026-08-20 (UTC+11) the tunnel data-plane starts dying periodically (every 15–60 min); by ~12:13 local the client cannot connect at all.
3. `adguardvpn-cli connect` fails with:
```
ERROR CLI_APP ~CliApp: Command finished with error:
> None of the endpoints are available
```
4. At the same moment, plain TCP to every known endpoint on :443 from the same host **succeeds** (verified with `timeout 5 bash -c "echo > /dev/tcp//443"` for each one) — connections are established at TCP level but killed at the protocol level.
5. Routing the client's own traffic through another VPN tunnel **restores full connectivity** to the same endpoints from the same host.
6. After upgrading to v1.8.1-nightly.1 the client connects directly again and stays connected (as of ~16:20 UTC+11).

### Expected Behavior

- The transport should withstand TSPU/DPI signature-based interference (masking, endpoint rotation, or graceful fallback), so the tunnel keeps working from Russia during the day.
- When an upstream endpoint dies silently, the client should detect the dead data-plane and reconnect to a fresh endpoint automatically, without the process just sitting on dead connections.

### Actual Behavior

Two distinct problems observed on v1.7.12:

**1) Signature-based DPI blocking (time-of-day dependent):**
- Night (12+ hours of uptime): perfectly stable.
- Morning: data-plane dies every 15–60 min; the daemon process keeps running while no data flows, and there is nothing in the logs.
- Midday: complete block — `connect` exits with "None of the endpoints are available", while plain TCP :443 to every endpoint still succeeds (protocol layer killed after establishment).
- Encapsulating the client's traffic in another VPN tunnel makes the same endpoints work again from the same host — confirming DPI/TSPU as the cause.

**2) No auto-recovery on silent endpoint loss:**
Several times the data-plane stopped while the daemon stayed alive: TCP connections dead, no data flow, no log entries at all, `status` still reported connected. A manual service restart (which picks fresh endpoints) fixed it instantly every single time. With `--no-fork` under systemd this has to be covered by external watchdogs.

Endpoints observed during the incidents: `23.27.246.168, 103.115.19.250, 103.115.19.170, 138.124.33.46, 89.125.13.207, 104.154.125.27, 149.102.254.129, 104.143.217.188`

### Screenshots

Screenshot 1

### Additional Information

- v1.8.1-nightly.1 currently connects directly where 1.7.12 could not. Not sure yet whether it's better protocol masking or just fresh endpoint ranges — tomorrow's DPI window will tell. Happy to report back with results.
- journald logs from the v1.7.12 incidents are available on request.
- Context: we run the CLI as a policy-routing gateway for a small office; the `NONE` routing mode + `set-bound-if-override` make it an excellent fit for this use case. Thanks for the great tool!