v1.6.0

<details open>
<summary>🇷🇺 Что нового (RU)</summary>

## Что добавляет этот релиз

`v1.6.0` чинит давнюю проблему: **мобильный Telegram (наблюдалось на iOS), провисевший в фоне часами — например, ночь — без выгрузки из памяти, при возврате зависает в статусе «обновление»**, пока не переключишь прокси. Поведение по умолчанию не меняется — фикс opt-in, апгрейд безопасен.

## Причина

Мобильный клиент держит **одно** TCP-соединение часами. За это время congestion window ядра схлопывается (тяжёлые ретрансмиты + reordering). На проде поймали соединение возрастом **8.5 ч**: `cwnd:10`, `bytes_retrans:18721`, `reord_seen:1188`, проток ~20 Б/с — клиент всё ещё активно обменивался, просто еле-еле. При возврате клиент переиспользует этот деградировавший сокет → ресинк ползёт → «обновление» висит. Переключение прокси помогает именно потому, что создаёт свежее соединение.

## Решение

Новая opt-in опция **`max_connection_lifetime_sec`** (по умолчанию `0` = без лимита, поведение байт-в-байт прежнее). Релей старше лимита пересоздаётся через **TCP RST** (`SO_LINGER{0}`) → клиент сразу открывает чистое соединение, Telegram прозрачно подхватывает поверх короткого разрыва.

```toml
[server]
max_connection_lifetime_sec = 1800   # 30 мин; 0 = выкл (дефолт). Пробуйте 1800–3600
```

## Проверено на живом проде

Развёрнуто на `proxy.sleep3r.ru` с `cap=120`: журнал подтвердил `recycling relay: lifetime cap 120s reached (RST -> fresh reconnect)`, клиент чисто переподключился, `active` стабилен, `NRestarts=0`, ошибок нет. Прод выставлен на `1800`. `zig build test` зелёный, кросс-сборки + install-матрица (debian 11/12, ubuntu 20.04/22.04/24.04) + E2E + bench — всё зелёное.

</details>

---

<details>
<summary>🇬🇧 Release notes (EN)</summary>

## What this release adds

`v1.6.0` fixes a long-standing issue: **a mobile Telegram (observed on iOS) backgrounded for hours — e.g. overnight — without being unloaded from memory sits in the "updating" status on resume** until you switch proxies. Defaults are unchanged — the fix is opt-in and the upgrade is safe.

## Root cause

A mobile client keeps **one** TCP connection alive for hours. Over that lifetime the kernel congestion window collapses (heavy retransmits + reordering). On prod we caught an **8.5h** connection with `cwnd:10`, `bytes_retrans:18721`, `reord_seen:1188`, throughput trickling at ~20 B/s — the client was still actively exchanging, just crawling. On resume the client reuses that degraded socket, so the re-sync trickles and "updating" hangs. Switching proxies works precisely because it forces a fresh connection.

## The fix

New opt-in option **`max_connection_lifetime_sec`** (default `0` = unlimited, byte-identical behavior when unset). A relay older than the cap is recycled with a **TCP RST** (`SO_LINGER{0}`), so the client immediately opens a clean connection and Telegram resumes transparently across the brief drop.

```toml
[server]
max_connection_lifetime_sec = 1800   # 30 min; 0 = off (default). Try 1800–3600
```

## Validated on live prod

Deployed to `proxy.sleep3r.ru` at `cap=120`: the journal confirmed `recycling relay: lifetime cap 120s reached (RST -> fresh reconnect)`, the client reconnected cleanly, `active` stable, `NRestarts=0`, no errors. Production value set to `1800`. `zig build test` green, plus cross-builds + install matrix (debian 11/12, ubuntu 20.04/22.04/24.04) + E2E + bench — all green.

</details>

---

**Full Changelog**: https://github.com/sleep3r/mtproto.zig/compare/v1.5.0...v1.6.0