swift15: all experts through GPTQ w4 (plugin one-table-one-encoding law)

rad_arch_declare rejects the split tier (down block-fp8 + gate_up w4): the
qwen4exp_fp8 kernel serves one encoding per expert table (w4nl64a8h) with only
whole bf16 experts beside it. Recipe now sends gate_up AND down through the
GPTQ w4 rule (down calibrated by the Grams, gate_up uncalibrated), drops the
down-fp8 rule, and lowers the size floor 126000->108000 MiB for the ~19 GiB
lighter container. Convert script: checkpoint lives under models/ukisai/, and
the in-container path must keep the subdir (basename stripped it).

scripts/recipes/qwen4exp-swift15-w4dn8-i8-hc8m.recipe

@@ -1,18 +1,18 @@
 # qwen4exp-swift15-w4dn8-i8-hc8m.recipe -- the Swift 1.5 finetune of Qwen3.8-Flash-Next
-# (ukisai/Swift1.5-Qwen3.8-Flash-Next, BF16, 335.3 GiB, key set identical to the official base) as
-# a radiance container for frank-primary: every routed expert's DOWN projection at block-fp8 --
-# the same tile form the served FP8-native container already holds (E4M3 codes, one bf16 scale a
-# 128x128 block, the minicpm5-2b amax/448 rule) -- and its gate_up at four bits, the served recipe's
-# w4nl64a8h encoding. The rest is qwen4exp-w5dn64-i8-hc8m.recipe verbatim: int8 trunk linears,
-# block-fp8 hc mixers and MTP fc, the fixed-scale n-gram table, the 2-bit draft head.
+# (ukisai/Swift1.5-Qwen3.8-Flash-Next, BF16 source, 335.3 GiB, key set identical to the official
+# base) as a radiance container for frank-primary: EVERY routed expert -- gate_up AND down --
+# through GPTQ into the w4nl64a8h table. The plugin's one-table-one-encoding law
+# ("one table of experts takes one encoding, and only a whole expert kept plain bf16 is served
+# beside it", qwen4exp_fp8 rad_arch_declare) forbids the original split tier (down block-fp8 +
+# gate_up w4): the served kernel is w4nl64a8h for the whole expert set, bf16 experts beside it.
+# The rest is qwen4exp-w5dn64-i8-hc8m.recipe verbatim: int8 trunk linears, block-fp8 hc mixers
+# and MTP fc, the fixed-scale n-gram table, the 2-bit draft head.
 #
-# Down first because down is the larger share of an expert's output error (held-out relative error
-# 0.094 against gate_up's 0.064 on the base model), and fp8 buys it a full binade for 2x the bytes
-# of w4 -- while gate_up, three quarters of the expert's weights, stays at 4 bits. Expert mass:
-# gate_up 150.00 GiB -> ~37.6 GiB, down 75.00 GiB -> ~37.7 GiB: ~75 GiB of experts, ~38 GiB a rank
-# at TP=2, inside the 40960 MiB host pool. The published w5dn64 comparison (mean KL 0.0789 ->
-# 0.0717, top-1 92.85% -> 93.34%, decode +4%, prefill -19%) is the 5-bit upper bound; this tier
-# trades part of that quality back for prefill.
+# Why down is the calibrated half: the calibration tap rides the down projection, so its GPTQ
+# rounding propagates against real down-input Hessians; gate_up shares the same w4 table
+# uncalibrated. The published w5dn64 comparison (mean KL 0.0789 -> 0.0717, top-1 92.85% ->
+# 93.34%, decode +4%, prefill -19%) is the 5-bit upper bound; this tier trades part of that
+# quality back for prefill.
 #
 #   CALIB=DIR rad-convert <Swift1.5-Qwen3.8-Flash-Next checkpoint> \
 #       --recipe scripts/recipes/qwen4exp-swift15-w4dn8-i8-hc8m.recipe -o qwen4exp-swift15-w4dn8-i8-hc8m.rad
@@ -43,16 +43,13 @@ blk.47.ffn_*_exps.399.weight         cast dtype=bf16
 blk.47.ffn_*_exps.445.weight         cast dtype=bf16
 # PROTECTED-END
 
-# Every other routed expert, trunk and MTP layer alike: the down projection as E4M3 codes with a
-# bf16 scale a 128x128 block -- one amax per block, scale = amax/448 rounded to bf16, the exact
-# tile form modelopt ships and the served FP8-native container holds, so the moe_gemm_fp8a8 kernel
-# reads it unrep permuted; and the gate_up as u4 codes into the w4nl table, rotated by the 128-wide
-# Hadamard, an E4M3 scale a group of 64 under the fixed 2^-13 searched for least error as stored,
-# chosen by GPTQ against $CALIB and swept three times by coordinate descent. The down shapes tile
-# exactly: [2560, 640] -> 20x5 blocks, [1280, 2560] -> 10x20. The MTP layer has no recording, so
-# its down is rounded to nearest anyway and its gate_up quantises uncalibrated -- both said on
-# stderr, as the base recipe says.
-blk.*.ffn_down_exps.*.weight         rtn  codes=fp8_e4m3 block=128x128 scale=bf16
+# Every other routed expert, trunk and MTP layer alike: u4 codes into the w4nl table, rotated by
+# the 128-wide Hadamard, an E4M3 scale a group of 64 under the fixed 2^-13 searched for least
+# error as stored, chosen by GPTQ against $CALIB and swept three times by coordinate descent.
+# The calibration Grams are down-input Hessians, so down is the calibrated half of the table;
+# gate_up has no recording of its own and quantises uncalibrated (said on stderr, as the base
+# recipe says). The MTP layer has no recording either. Expert mass: gate_up 150.00 GiB -> ~37.6,
+# down 75.00 GiB -> ~18.8: ~56 GiB of experts, ~28 GiB a rank at TP=2 -- well inside the pool.
 blk.*.ffn_*_exps.*.weight            gptq table=w4nl group=64 scale=fp8_e4m3 scale2=f32 block2=*x* scale2_value=0.0001220703125 transform=fwht128 rule=search cd=3 calib=$CALIB
 
 # Every connection's two mixing matrices -- the 96 trunk connections, the final mixer and the MTP