ci: a dispatchable workflow that re-runs the CUDA path

[vyncint]

Nothing automated has ever run this project's CUDA path. There is no GPU job in any workflow, crates/launchbound-bench/src/cuda.rs has no test that executes, and the headline result in the README — the A10G sweep where six refused configurations measured up to 3.00x faster — was produced by hand on 2026-08-20 and has not been reproduced since.

Between then and now the lockstep pin set moved twice, cuda-oxide is three commits past the pin (#70), and docs/LIMITATIONS.md already records a known way for the compile step to break: cargo check under the reconverge driver does not evaluate all codegen-time consts, so a gate-clean candidate can still fail to build. Nothing would have told us if it had.

The shape

Two jobs, split the way stage and launchbound-runner were designed to be split:

• stage (ubuntu-latest) prunes and compiles every admitted specialization, and builds the box-side binary beside the plan. So the expensive machine needs a CUDA driver and nothing else — no toolchain, no cuda-oxide checkout, no analyzer.
• measure runs on ${{ inputs.runner }}, default gpu, records the device and driver before measuring anything, runs the sweep under an enforced --budget-secs, and uploads results.json on every exit path.

workflow_dispatch only. It never runs on a push or a schedule, because it costs money. With -f measure=false it stages a plan and stops, which is the path for a box you drive by hand:

./launchbound-runner --budget-secs 900 plan.json results.json

the same command the workflow issues.

What it gates on, and what it refuses to

The claims that port: the results declare results.v1; no candidate in the results is absent from the plan; no admitted candidate failed to run; something was measured. An admitted candidate that failed is reported by id rather than tolerated — each one names another codegen-time const the gate does not evaluate.

Not the timings. Those are valid only for the GPU, driver and compiler in their provenance, and sm_75 and sm_86 do not transfer (docs/LIMITATIONS.md, "Results do not port"). The job prints the five fastest with the device, driver and plan capability beside them, and uploads the results. Asserting a number here would be asserting exactly the thing this project documents as non-transferable.

What it does not do, deliberately

It does not provision the machine. This repository holds no cloud credentials, and adding one is a decision with a blast radius rather than a workflow detail. The issue's sketch had the workflow creating and terminating an instance; that is the half that belongs to whoever owns the account.

Not verified

There is no GPU available to this change, so the workflow is written, actionlint-clean and zizmor-clean, and unexercised. #83 asks for "one green run recorded, with its provenance, at the current pin set" and that part is not done — the issue should stay open until someone dispatches it against a real box.

Refs #83