CI: recover when Pantry Zig downloads stall

Observed in main CI run 29712223299: Pantry's zig@0.17.0-dev archive download stalled twice for 60 seconds, the action still completed successfully, and every dependent job failed immediately with zig: command not found.

Scope

• Keep Pantry as the primary toolchain setup.
• Continue only its setup step on transport failure or missing installation.
• If no Zig executable exists, resolve the current master artifact from the official ziglang.org download index for the runner OS/architecture.
• Verify the published SHA-256 before extraction and add the exact binary directory through GITHUB_PATH.
• Apply the same hardened setup to ordinary CI, TSan/test262 jobs, and the manual performance workflow.

Acceptance

• Existing Pantry installations remain the fast path.
• A missing Pantry binary triggers the verified official fallback.
• Unsupported hosts and checksum/download failures fail explicitly.
• Workflow YAML and both local fast/fallback paths are validated.
• A descendant main CI run gets past toolchain setup.

Implemented and pushed as f54aa804. Pantry remains the primary setup and is allowed to fail transport/setup; every CI, TSan, test262, and manual performance path then runs a shared verifier. If zig is absent, it resolves the current runner artifact from the official ziglang.org master index, verifies the published SHA-256, extracts it, and appends the exact binary directory through GITHUB_PATH. Unsupported hosts, missing artifacts, checksum failures, and failed downloads are fatal.

Validated locally: existing Pantry fast path; deliberately hidden-zig fallback downloaded/verified/executed Zig 0.17.0-dev.1426 on arm64 macOS; both workflow YAML files parse; temp archive/tree deleted. Keeping open until the descendant main run gets past setup.

Confirmed fixed by descendant Actions run 29714290629. Pantry setup and the Ensure Zig is available recovery step both complete successfully across jobs, and downstream unit, test262, benchmark-harness, private-ABI, threads, and TSan work is building/running successfully. This is the real hosted-run evidence the issue was waiting for.