qwen35moe (Qwen3.5-35B-A3B, hybrid Gated DeltaNet + MoE): CPU and CUDA forward #4801

Status on main 6192aa9: apr refuses the architecture by name.

• apr run --gpu gives rc=12: "this build has no CUDA forward for architecture 'qwen35moe' ... This is a refusal, not a fallback".
• Without --gpu, or with --no-gpu, it gives rc=8: "There is no CPU or GPU forward for architecture 'qwen35moe' with SSM tensors".
• The model ladder row is excused by red_unsupported["Qwen3.5-35B-A3B*.gguf"]. That key cites 0.70.0: qwen35moe (Qwen3.5-35B-A3B hybrid SSM MoE) CUDA forward #3977, which was closed as parked, so this ticket takes its place.

Scope:

• A CPU forward: the qwen35 hybrid layers (CPU: Qwen3.5 / Qwen3.8 hybrid GGUFs are refused entirely — no fallback exists #3091) combined with MoE expert routing (the qwen3moe pattern).
• A CUDA forward: the qwen35 hybrid path (GPU: implement Gated DeltaNet / SSM inference for Qwen3.5 / Qwen3.8 hybrid GGUFs #3090) combined with the qwen3moe CUDA MoE (qwen3moe (Qwen3-30B-A3B, Qwen3-Coder-30B-A3B, Q4_K_M) has NO working CUDA path: apr run --gpu falls back to CPU (rc 14), apr qa emits no gates — blocks 0.69.1 under the all-Q4_K-CUDA rule #3714).
• Dequant coverage for every qtype in the UD-IQ4_XS file.

Done when:

1. apr run --gpu on Qwen3.5-35B-A3B-UD-IQ4_XS answers ctl-2plus2 with ran=gpu fell_back=false.
2. On the same prompt, CPU and GPU agree within the ladder's parity rule.
3. The red_unsupported key is deleted in the same PR. The checker refuses a key that matches a green row.

Not: a 0.70.2 P0. It is architecture work.

Ruled out of 0.70.2 (#4665 is re-ruled to refused-by-name).

Agent: aprender-w4578