v0.22.1

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

## Что решает этот релиз

`v0.22.1` - небольшой patch-релиз для `mtbuddy update`, `mtbuddy install` и `deploy/bootstrap.sh`.

После `v0.22.0` на реальном VPS проявилась неприятная проблема с GitHub release assets: сам релиз находился, `.tar.gz` и `.minisig` могли скачиваться, но обычный `curl -L` до маленького `.sha256` файла стабильно уходил в SSL timeout. При этом тот же URL сразу открывался через `curl -4`.

Это не проблема подписи, checksum или отсутствующего asset. Это типичная CDN/DNS/IPv6/HTTP2 хрупкость на конкретном маршруте до GitHub Releases. Старый updater воспринимал такой timeout как "артефакт не скачался" и останавливал обновление.

В `v0.22.1` загрузчик релизов стал устойчивее:

1. обычный `curl`;
2. fallback через IPv4 (`curl -4`);
3. fallback через HTTP/1.1;
4. fallback через IPv4 + HTTP/1.1.

При этом security model не ослаблен: `.sha256` всё ещё обязателен, minisign-подпись всё ещё проверяется до доверия к checksum, а архив не распаковывается и бинарник не запускается до успешной проверки.

> [!NOTE]
> Если `v0.22.0` уже установлен и работает, обновление до `v0.22.1` нужно прежде всего для более надёжных будущих `mtbuddy update` / bootstrap сценариев.

> [!IMPORTANT]
> `--insecure` поведение не изменилось. Unsigned mode по-прежнему доступен только явно через `--insecure` или `MTPROTO_INSECURE=1`.

## Что изменено

### Устойчивые загрузки GitHub release assets ([#242](https://github.com/sleep3r/mtproto.zig/pull/242))

- `mtbuddy` теперь пробует несколько curl-режимов для каждого release-файла:
  - default;
  - IPv4;
  - HTTP/1.1;
  - IPv4 + HTTP/1.1.
- Это применяется к:
  - proxy `.tar.gz`;
  - `mtbuddy` `.tar.gz`;
  - `.sha256`;
  - `.sha256.minisig`.
- Неуспешные/частичные файлы удаляются перед следующей попыткой.
- Пустой файл больше не считается успешной загрузкой.

### Bootstrap использует ту же download-логику ([#242](https://github.com/sleep3r/mtproto.zig/pull/242))

- `deploy/bootstrap.sh` получил общий `curl_download` helper.
- Fallback применяется не только к tar/checksum/signature, но и к запросу latest release metadata.
- One-liner install стал менее зависим от конкретного GitHub CDN edge.

## Проверено

- `bash -n deploy/bootstrap.sh`
- `zig fmt src/ctl/release.zig`
- `make test`
- `zig build -Doptimize=ReleaseFast -Dtarget=x86_64-linux -Dcpu=x86_64_v3+aes`
- patched `mtbuddy` был проверен на `proxy.sleep3r.ru`: `mtbuddy update --version v0.22.0` успешно прошёл путь, который раньше падал на checksum download; `mtproto-proxy` остался `active`.

</details>

---

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

## What this release addresses

`v0.22.1` is a small patch release for `mtbuddy update`, `mtbuddy install`, and `deploy/bootstrap.sh`.

After `v0.22.0`, a real VPS exposed an unpleasant GitHub Releases edge case: the release itself resolved correctly, `.tar.gz` and `.minisig` files could download, but a normal `curl -L` request for the small `.sha256` file consistently timed out during SSL setup. The same URL succeeded immediately with `curl -4`.

This was not a missing asset, checksum bug, or signing problem. It was the kind of CDN/DNS/IPv6/HTTP2 route fragility that can happen on specific paths to GitHub Releases. The old updater treated that timeout as a hard artifact download failure and stopped the update.

`v0.22.1` makes release downloads more resilient:

1. normal `curl`;
2. IPv4 fallback (`curl -4`);
3. HTTP/1.1 fallback;
4. IPv4 + HTTP/1.1 fallback.

The security model is unchanged: `.sha256` is still required, the minisign signature is still verified before trusting the checksum, and archives are not extracted or executed until verification succeeds.

> [!NOTE]
> If `v0.22.0` is already installed and running, upgrade to `v0.22.1` mainly for more reliable future `mtbuddy update` / bootstrap flows.

> [!IMPORTANT]
> `--insecure` behavior has not changed. Unsigned mode still requires explicit `--insecure` or `MTPROTO_INSECURE=1`.

## What changed

### Resilient GitHub release asset downloads ([#242](https://github.com/sleep3r/mtproto.zig/pull/242))

- `mtbuddy` now tries several curl modes for every release file:
  - default;
  - IPv4;
  - HTTP/1.1;
  - IPv4 + HTTP/1.1.
- This applies to:
  - proxy `.tar.gz`;
  - `mtbuddy` `.tar.gz`;
  - `.sha256`;
  - `.sha256.minisig`.
- Failed/partial files are removed before the next attempt.
- Empty files are no longer accepted as successful downloads.

### Bootstrap uses the same download logic ([#242](https://github.com/sleep3r/mtproto.zig/pull/242))

- `deploy/bootstrap.sh` now has a shared `curl_download` helper.
- The fallback logic applies to latest-release metadata as well as tar/checksum/signature downloads.
- One-liner install is now less dependent on a single GitHub CDN edge behaving perfectly.

## Verified

- `bash -n deploy/bootstrap.sh`
- `zig fmt src/ctl/release.zig`
- `make test`
- `zig build -Doptimize=ReleaseFast -Dtarget=x86_64-linux -Dcpu=x86_64_v3+aes`
- patched `mtbuddy` was tested on `proxy.sleep3r.ru`: `mtbuddy update --version v0.22.0` completed the path that previously failed on checksum download; `mtproto-proxy` remained `active`.

</details>

## Changelog

* fix: add release asset download fallbacks ([#242](https://github.com/sleep3r/mtproto.zig/pull/242)) ([133f53c](https://github.com/sleep3r/mtproto.zig/commit/133f53cd55c35338a4f09ab913657ab63a27ed6b))
* fix: add release asset download fallbacks ([#243](https://github.com/sleep3r/mtproto.zig/pull/243)) ([813dc8d](https://github.com/sleep3r/mtproto.zig/commit/813dc8d3a0785930badd06f7ba59a37d790be7d4))
* chore(main): release 0.22.1 ([#244](https://github.com/sleep3r/mtproto.zig/pull/244)) ([2d8eafe](https://github.com/sleep3r/mtproto.zig/commit/2d8eafe802b5bcc18789b9f56adfe5f31f0afe6b))