feat: automatically resolve zig instead of requiring an exact system version

[CptnKirk]

Burrito currently requires the system zig on $PATH to match its pinned version exactly (check_zig_version/0 in lib/burrito.ex, exit(1) on any mismatch). Every zig version bump — 0.15.2, then 0.16.0 — breaks every downstream project until each one manually reinstalls the new pinned zig. There's also no way to build at all without a system zig present.

This is causing me pain since Expert (lsp server) ships as a burrito but can't know what version of zig, if any, will be installed on build hosts. My fix is for Burrito to manage its own zig dependency automatically, the same way it already manages its own ERTS dependency, rather than requiring the build host to have the right one pre-installed.

Fix: Burrito.Util.ZigResolver resolves zig automatically, in order:

1. BURRITO_ZIG_PATH env var, if set — an explicit override, still validated (must exist and report the pinned version) rather than trusted blindly.
2. A previously downloaded, managed copy at the pinned version, if already cached.
3. System zig on $PATH, if its version matches the pinned version exactly — unchanged behavior for anyone already correctly set up.
4. Otherwise, download the pinned version for the host OS/CPU, verify its sha256 checksum against a pinned table, cache it, and use that.

Only the exact pinned version is ever used to build — build.zig has historically only compiled against one zig API generation at a time (see the 0.15 → 0.16 migration), so this isn't a relaxation of which zig gets used, just of what has to already be on the system.

Wiring:

• New Burrito.Steps.Fetch.ResolveZig step, added to the :fetch phase, sets context.zig_bin (or halts with a logged error).
• context.zig_bin threaded through both existing System.cmd("zig", ...) call sites in pack_and_build.ex and through NIF cross-compilation env vars (CC/CXX/AR/RANLIB) in recompile_nifs.ex, shell-quoted since the resolved path can contain spaces.
• check_zig_version/0 removed from lib/burrito.ex; pre_check/0 still checks for xz, and now warns instead of hard-erroring on missing 7z/7zz.
• Extracted the proxy-aware download logic (previously duplicated across fetch_musl.ex, default_erts_resolver.ex, and now this) into a shared Burrito.Util.Downloader.

Also touches CI — calling this out separately since it's not just application code: added two new jobs to burrito-xcomp-check.yaml, build_no_system_zig and build_wrong_system_zig, mirroring build_examples's existing shape. Each builds and runs the cli_example release on ubuntu-latest — one with no zig on $PATH at all, one with the prior 0.15.2 pin present instead of the current one — so both resolver fallback tiers stay covered automatically on every future PR. Happy to split this into its own PR if you'd rather review the CI change separately from the resolver itself.

Verified against both real failure modes, twice over: first by building expert (the official Elixir LSP, whose justfile depends on Burrito) end-to-end on two isolated Fly Sprites — one with no zig installed at all, one with zig 0.15.2 present (incompatible with the 0.16.0 pin) — both of which fail on main today and succeed on this branch; then again by the two new CI jobs above, which exercise the same two scenarios automatically going forward.

Kept intentionally narrow: this branch is independent of #229/#230 (the unrelated argv/VM-halt regression) and builds cleanly against current main. Combined end-to-end validation against #230 was done in a separate, throwaway branch, not included here.