campaign(qwen38): the tap producer is latest radiance, at a vendor-backed floor

The tap did not arm on the production pin: a 17-hour calib run on 1.8.1
wrote zero bytes while /health, /stats and the push all read healthy.
On :latest (v1.14.0, revision 4a61d7296bc5) the same boot prints
'recorded passes: off, the program accumulates calibration Grams
(gram_accum)' and a 9,129-token push sealed 24,768 gram files (42.9 GB)
in the fitting shape - 4 slots at a 2,048-token step, production's own.

The vendor's calibration shape (--max-num-batched-tokens 65536,
--max-num-seqs 64, ~930 tok/s) cannot boot two 32 GiB R9700s: the
activation arena alone is 12.83 GiB of the 27.95 GiB claimable, and
every variant stops in the VRAM resolver (short 3.19 GiB .. 86 MiB,
then a starved cache).

Floor moves 12M -> 1.5M tokens: the vendor's own measurement is 'a
pooled Gram from 10M tokens beat one from 1M by under 1%', and 1.5M is
hours at this rig's rate instead of the 29 h a 6M floor cost.

The converter moves to the same digest: rad-convert's gptq:calib=<dir>
input is version-stable, so a latest-written tap converts on latest.

tests/qwen38_reference.bats

@@ -157,12 +157,15 @@ flag_value() {
     [[ "$output" != *"--vram-kv-mib"* ]]
 }
 
-@test "the calib dry run opens the tap at 12M tokens and serves on 7770" {
+@test "the calib dry run opens the tap at the 1.5M floor, on the latest pin, and serves on 7770" {
     run bash "$RUNNER" calib --dry-run
     [ "$status" -eq 0 ]
     flat="$(oneline)"
-    [[ "$flat" == *"-e RADIANCE_CALIB_TOKENS=12000000"* ]]
+    [[ "$flat" == *"-e RADIANCE_CALIB_TOKENS=1500000"* ]]
     [[ "$flat" == *"-e RADIANCE_CALIB_DIR=/data/calib"* ]]
+    # the tap producer is the campaign's own pin (latest radiance), not production's
+    [[ "$flat" == *"radiance@sha256:69add58f"* ]]
+    [[ "$flat" != *"radiance@sha256:d590e300"* ]]
     [[ "$flat" == *"--port 7770"* ]]
     [[ "$flat" == *":/data/calib "* ]]
     # calib serves; it does not record