A mistyped `--cc` costs eleven subprocesses and prints ninety lines of the wrong error

[vyncint]

Reproduce

$ launchbound prune reduce-flip --cc 80

8.6 is the documented form — --cc's own help says "8.6 for A10G, 7.5 for T4". 80 is the CUDA sm_80 spelling, which is what a CUDA user reaches for first.

What happens

Eleven cargo reconverge subprocesses are spawned, one per configuration, and every one fails identically. 90 lines of output, eleven repetitions of this:

  ! c1-9b9fe33407467e5e  block_x=32 tile=128
      TOOL ERROR (hard stop): cargo reconverge exited 2:
                              with their recorded reasons

Exit codes: 0 = no findings at deny/confirmed confidence, 1 = findings,
2 = tool error. Findings accepted by the baseline never gate the exit
code, and their count is always reported.

The actual cause appears nowhere in those 90 lines. reconverge said it perfectly, on the first line of its stderr:

error: `80` is not a compute capability; expected e.g. `8.6`

(Why it gets lost is a separate defect — see the sibling issue about the stderr tail.)

Every malformed value behaves the same way. Measured:

--cc	exit	time	TOOL ERROR blocks
80	2	106ms	11
8.6.1	2	105ms	11
abc	2	106ms	11
`` (empty)	2	105ms	11
999	2	105ms	11

Why it is worth fixing

--cc is required on prune and on model, so it is the first thing anyone types after the kernel name — and the CUDA spelling (80, 86) is the one a GPU person already has in their fingers. The first mistake a new user is likely to make produces the tool's worst output.

It is also eleven process spawns to learn something knowable before the first one. On a six-kernel corpus run (launchbound prune --cc 80 with no kernel) it is 101 spawns.

Fix

Validate --cc in the CLI, before any work: a decimal major.minor, and — better — against the same device table launchbound model already consults, since a capability the model cannot cost is not one prune should accept either. One line of output, immediately:

error: `80` is not a compute capability — did you mean `8.0`?
       known: 7.0, 7.2, 7.5, 8.0, 8.6, 8.9, 9.0

Mapping the CUDA sm_NN spelling (80 → 8.0, 86 → 8.6) rather than rejecting it is worth considering; it is unambiguous for every two-digit value in the table.

Done when

A malformed --cc produces one line naming the problem and the accepted values, spawns nothing, and exits 2.