[DO NOT MERGE] test: swap testrunner hack for buildkit passthrough op

[cpuguy83]

What this is

A feasibility test for the new buildkit passthrough op from moby/buildkit#6829 (which fixes moby/buildkit#6809 — that issue cites dalec's testrunner hack as the motivation). Not for merge: back-compat is intentionally out of scope, and go.mod is pinned to an unmerged buildkit fork.

Testrunner change

dalec's testrunner currently fakes "run for validation only, discard fs changes, but force the op to build" with a no-op true exec + readonly rootfs + discard mount, plus a diff/merge to strip test diffs. This swaps that for State.Requires(id, deps...):

• doValidate — runs the validation as a writable-rootfs exec and attaches it to the input as a build-only dependency (in.Requires(...)), instead of a readonly exec consumed via a discard AddMount. The validation filesystem is discarded; only the pass/fail edge is kept.
• mergeStateOptions — forces each check to build as a build-only dependency of the input (output = input) instead of diff+merge. Contract narrows from "merge branch diffs" to "force branch builds"; sound because every current testrunner option is validation-only.
• noopCommand.WithOutput / WithFinalState — returns out.Requires(id, in).
• Unit tests marshal from a base state with a real output (passthrough rejects a nil-output receiver) and drop the obsolete __internal_state mount assertions.

CI: running against a custom buildkitd

The op bakes the passthroughop capability into the LLB, so a stock buildkitd rejects it. Every CI job that solves a dalec spec must use the PR daemon:

• New build-buildkit prep job builds buildkitd from tonistiigi/buildkit@passthrough-op (from a local clone with tags, so version detection yields a usable version — the harness gates on >= 0.12) and pushes it to ghcr.
• integration and e2e jobs now create a docker-container builder from that image (BUILDX_BUILDER, --bootstrap, a buildkitd --version smoke check, and PR-buildkitd log capture on failure). For integration, the prebuild bakes are cache-warming on that same builder; the harness rebuilds the frontend/workers from source in-graph.

Trade-offs / notes

• The passthrough vertex carries no progress group / platform / source location (State.Requires takes no ConstraintsOpt) — cosmetic.
• Failure is only re-observed on a cache miss (Requires deps can be cache-served); existing negative fixtures use fresh inputs, which is sufficient.

Local validation passes: go build ./..., go test --test.short ./..., go run ./cmd/lint ./..., go generate (no diff). The real signal is whether the integration + e2e suites stay green against the custom buildkitd in CI.