feat(BACKEND-ROCM): register kFusedNormRope, so GLM-5.3 stops taking the path a keep-quant MLA checkpoint cannot survive

[localai-org-maint-bot]

GLM-5.3 loads on strix:gpu0 and emits nothing. The first forward throws in the
MLA block, and the cause is not the op call -- it is the branch above it.

mla_attention.cpp's fused_nr predicate ends in
vt::OpRegistered(kFusedNormRope, device). That is a native-only probe by
design (src/vt/op_provider.cpp:779-803), and ROCm registered no such kernel.
So with every environment variable unset the predicate was false on gfx1151,
the split A-projection path was taken, and it row-slices kv_a_proj_with_mqa --
which this checkpoint's q8_0 weight has no way to provide, because a quant
block spans whole rows.

That makes kFusedNormRope unlike the seven other MLA/DSA ops ROCm still lacks.
Each of those has a CPU registration, so on this host-addressable board each
falls through to the portable reference tier and merely runs on the host. This
one is consulted BEFORE the call, so its absence is a refusal rather than a
slowdown, and it was the only thing between this model and a token.

Why this repair and not the other two

#2564 prices three. This takes the first and says why it declines the others.

Widening OpRegistered to see the reference tier would change what "available"
means at a shared seam for every backend and every op, and op_provider.cpp
states the contract it would break: a unified accelerator would report every op
registered the moment its fallback installed, and the fused-recipe ladder would
stop choosing its portable composite path. It also keys naturally on
host-addressability, and the two host-addressability predicates disagree on this
board -- DeviceMemoryIsHostAddressable() is true, which is what makes the
reference tier eligible at all, while HostMemoryIsDeviceAddressable() is false
because gfx1151 reports pageableMemoryAccess=0 (#2515, measured twice on
hardware). A predicate written against the wrong one reads plausible and answers
backwards on the only board that can test it.

Teaching the split path to slice a block-quantized row is the largest of the
three and repairs a fallback nobody wants taken, since the fused arm is
bit-identical and one launch cheaper. It stays owed in the spec.

What the kernel is

The composition of two kernels this backend already had natively:
rocm_rmsnorm.hip's shared-memory tree reduce, which uses no warp-level
primitive and is therefore wavefront-width agnostic, and
rocm_dense_basic.hip's cache-read rotation. kBlock stays 256 for the reason
rocm_rmsnorm.hip:41 already gives: four whole wavefronts, and the same
reduction ORDER as the CUDA and CPU siblings, which is what makes an NMSE bar
mean anything.

vLLM has no fused kernel for the pair, so upstream is the behavioural reference
and the in-tree CUDA sibling is the structural one. Read on the pin
5559679229: mla.py:164-165 splits the merged row and norms the latent half,
mla.py:175-177 ropes the trailing half, and deepseek_v2.py:512-518 fixes the
[kv_lora_rank + qk_rope_head_dim, hidden_size] shape both arms assume. The two
halves address disjoint dims, which is why fusing them is arithmetically inert.
One briefing anchor was wrong and is corrected in the spec:
GlmMoeDsaForCausalLM is at deepseek_v2.py:1930 at this pin, not in
deepseek_v32.py.

The message stopped naming one cause when there are two

The throw's comment enumerated the backends that HAVE the op -- CPU and CUDA --
and forgot the ones that do not, so it told a reader the only way there was
VT_MLA_FUSED_NORM_ROPE=0. It now reads the predicate terms back and says which
one was false, so a reader is not sent looking for a variable nobody set.

Evidence

strix:gpu0 (gfx1151, Radeon 8060S, ROCm 7.2.53211-97f5574fe2), under rc
leases, tree b413e323b. The tarball sha256 was read on both host and worker
and the two agree.

Build: ninja rc=0, [555/577] Building HIP object rocm_mla_fused_norm_rope.hip.o -- the first compile this TU has ever had.

GLM-5.3 e2e, through the production entry point (vllm-cli ->
vllm_engine_load -> ModelRegistry::Forward), greedy, rc=0,
prompt_tokens=5 completion_tokens=4 finish_reason=length:

 Paris, which is

op=114 device=5 selected=vt-native in that run -- op 114 is kFusedNormRope,
device 5 is kROCM. The id mapping is cross-checked three ways against the run's
own named lines (29/ConcatAndCacheMla, 99/ConcatMlaNopeRope,
33/MlaPrefillAttention).

Five ops served from the portable CPU reference tier in that run --
ConcatAndCacheMla, ConcatMlaNopeRope, MlaPrefillAttention,
BatchedMatmul, MlaDecodeAttention -- and kFusedNormRope is not among them.
No speed number is admissible from this run and none is offered.
docs/ROCM.md disqualifies a performance result with a non-zero reference-tier
hit count. The 3516.719 s for four tokens is the cost of a host-tier MLA arm,
not throughput.

Focused numeric gate: 1 test case | 1 passed | 0 failed,
20 assertions | 20 passed | 0 failed.

The assertion count is the discriminator, not a grep of the trace. CAPTURE
prints only on failure, so grepping a passing run for ROCM returns 0 and proves
nothing; that instrument is recorded as useless rather than quietly dropped. The
same case on a CPU-only build with no accelerator registered runs 2
assertions. 20 against 2 is the ROCm arm executing.

Mutation ladder, each rebuilt (a mutation the compiler kills is not a killed
mutation) and each restored before the next:

Mutation	Build	Result
M1: delete the RegisterOp(kFusedNormRope, kROCM) line	rc=0	LEG rc=1, the #2564 throw reproduced verbatim. KILLED
M2: drop the sin term from the rope half	rc=0	GATE1 rc=1, 1 case failed, 20 assertions / 18 passed / 2 failed. KILLED
restored control	rc=0	pre.sha == post.sha byte-for-byte on both files; GATE1 rc=0, 1 case / 20 assertions

M1 is both the RED and the reachability proof: the mutated tree is behaviourally
the base tree at the branch this repairs, and deleting the production call site
reds the production gate, which a by-hand construction cannot show. Its throw
also reads back the corrected message -- "the fused path was not taken because
this backend (rocm) registers NO NATIVE vt::FusedNormRope kernel".

Full cross-device suite: 29 cases | 28 passed | 1 failed,
80296 assertions | 80295 passed | 1 failed. The single failure is
MoeSiluMul's bit-exact bf16 CHECK(got == ref_b) at 1 ULP, which is the
standing red #1954 already tracks on gfx1200; the gfx1151 reading is recorded
on that issue. This change adds one TU and one registration and touches no MoE
path. It is not measured at the base commit on this board, so "pre-existing"
is argued from the absence of code-path overlap, not from an A/B.

Host-side control (CPU-only build, same tree): test_mla_attention_block
21 cases / 2,282,067 assertions green; whole cross-device suite 28 cases / 13
assertions green.

What is still owed

The seven other MLA/DSA ops on ROCm. Each has a CPU registration, so each serves
from the reference tier on this host-addressable board and none refuses -- they
are what makes a speed result inadmissible here, not what blocks a token. Listed
under ## Owed in the spec and owned by BACKEND-ROCM.

Closes #2564

FOLLOWING_AGENTS_PROTOCOL

Following-Agents-Protocol: true
AI-Assisted: true
Assisted-by: AGENT:claude-opus-5 [claude-code]