fix: bump mint/hpax/req to clear known security advisories

[CptnKirk]

mix.lock was pinning mint 1.7.1, hpax 1.0.2, and req 0.5.8, each of which has a known HIGH-severity advisory:

• mint 1.7.1: unbounded HTTP/2 CONTINUATION-frame and header-block accumulation, and unbounded PUSH_PROMISE stream growth (both DoS via memory exhaustion). Fixed in 1.9.0.
• hpax 1.0.2: unauthenticated DoS via unbounded HPACK integer decoding. Fixed in 1.0.3.
• req 0.5.8: decompression-bomb DoS via auto-decoded archive/compressed response bodies. Fixed in 0.6.0.

mix.exs already declares {:req, ">= 0.5.0"} with no upper bound, so a fresh install already resolves to the patched releases -- the vulnerable versions were only pinned because mix.lock hadn't been refreshed since they landed. No mix.exs constraint change needed, just the lock bump (finch also moves 0.19.0 -> 0.23.0, pulled in by mint/req's own tightened constraints; jason/mime/telemetry get minor bumps too).

Checked req 0.6.0's breaking change (dropping automatic archive-decoding, its own fix for the decompression-bomb advisory) against Burrito's actual usage: Burrito.Util.Downloader.get!/1 already calls Req.get!(url, raw: true), which disables all response auto-decoding on every Req version. So this doesn't affect Burrito's musl/ERTS/zig downloads at all.

mix hex.audit and mix deps.get no longer report any VULNERABLE! packages. Verified beyond the audit clearing: a full cross-compiled cli_example release still builds and runs on all 5 targets, and expert -- a downstream consumer -- still builds and runs correctly against this branch merged with the in-flight zig-auto-resolve work (#231).

[CptnKirk]

The CI failure here (build_examples_* 404ing on beam-machine-universal.b-cdn.net/OTP-27.3.4.15/...) is unrelated to this PR's changes.

erlef/setup-beam's floating otp-version: "27.3" resolved to 27.3.4.15, which was released two days ago (2026-07-27) — beam-machine-universal (the third-party precompiled-ERTS pipeline Burrito's fetch step pulls from) hasn't published a build for it yet. Confirmed directly: the CDN 404s on that exact version while every older 27.3.x patch returns 200, and #230 (unrelated PR, different diff) is failing with the identical error right now.

This matches the long-running pattern behind #170, #171, #178, #184, #193, #205, #207, #211, #212, #220, #223 — all "no precompiled build yet," all self-resolved within a few days once the CDN caught up. No action needed here; should go green once that happens.