Move build job's egress-policy to block, once mirror coverage is confirmed via audit mode

[purpleclay]

Background

release-rust.yml's setup_zig step originally pinned mirror: https://ziglang.org/download, intending to keep the download source fixed and egress-allowlist-friendly. That's wrong: mlugg/setup-zig explicitly rejects ziglang.org as a mirror override (to protect the official site from being hammered by CI) — the pin never actually worked, and the bug went uncaught until purpleclay/release-note became the first real consumer of this workflow and hit it in production: https://github.com/purpleclay/release-note/actions/runs/30449529929/job/90568000749

The immediate fix (done): drop the mirror: override entirely and let the action use its default behavior — a randomized pick from the live community mirror list (https://ziglang.org/download/community-mirrors.txt), falling back to the official site only as a last resort. build's harden_runner stays on egress-policy: audit for now.

Goal

plan and provenance have small, fixed, us-controlled network surfaces (GitHub API, Sigstore endpoints) and are reasonable block-mode candidates today. build is harder: the zig mirror is randomized and externally maintained, so a safe allowlist isn't knowable up front.

Audit mode logs every egress destination without blocking. Over enough real releases, randomization should surface every mirror currently in rotation, at which point we'd have real data to build a complete allowlist from (mirror list + ziglang.org fallback + any Sigstore/toolchain endpoints already in use) and move build to egress-policy: block.

Open caveat, not just the mirror

cargo build/cargo zigbuild also has to resolve and fetch every dependency in whatever Rust project calls this workflow — crates.io at minimum, but potentially more depending on what a given project's build.rs scripts or dependencies reach out to (vendored C libs, git dependencies, etc.). That surface is controlled by the calling project, not by release-workflows, and will differ per consumer (gpg-import, yam, release-note, ...). Confirm whether a single generic allowlist can actually cover this before committing to block mode — it may turn out build needs a per-consumer allowlist input, or needs to stay on audit regardless of the zig mirror being solved.

Acceptance criteria

• Audit-mode telemetry collected across enough real release runs to have observed the full current mirror rotation
• Confirmed whether crates.io/dependency-tree egress can realistically be covered by a single allowlist, or needs a different approach
• If viable: mirror: pinned to one mirror (or the full observed list added to allowed-endpoints) and build's harden_runner moved to egress-policy: block
• If not viable: this issue closed with the reasoning recorded, and build documented as staying on audit deliberately (not as a gap)