ci(parity): establish BuildKit as an explicit precondition of the parity lane

[pofallon]

Lands the buildx setup + verification step before the runner starts depending on it, so the runner change is never the thing that reddens the lane. First of step 7.

Why a precondition instead of a cleverer assertion

Declarative cases with a build operation need BuildKit. Without a precondition, the only way to express those cases was an outcome-conditional assertion — tolerating "succeeded OR failed" because BuildKit's presence was unknown.

That shape was nearly vacuous. Every one of those invocations passes --output-format json, and deacon's JSON error document also contains "outcome" — so the assertion held whichever way the build went. Establishing the precondition dissolves the need for that assertion shape entirely, rather than arguing about how to express it.

What the steps do

Step	Purpose
docker/setup-buildx-action@v3	ensures a builder exists (the runner ships buildx today, so this is mostly belt-and-braces)
docker buildx version + inspect --bootstrap	fails loud and early, so a missing builder cannot surface later as a build case reporting a divergence that is really a missing builder

The matching in-harness check (prereq::require_buildkit(), called for any case with a build op) follows in the next PR, so local runs get the same guarantee.

Verification

parity_registry_check 10/10 pass, including no_surface_globs_a_removed_path — the guard added in 023 T116 after two workflow steps silently globbed a removed path and kept exiting 0.

This PR touches only .github/workflows/parity.yml; the lane's existing redness (the 51 chan-structured-output T113 cases) is unchanged.

🤖 Generated with Claude Code

https://claude.ai/code/session_017UCGzJEFZd85HJqz1Wx2kE