[bong-water-water-bong]

Bumps third_party/llama.cpp 710c7c23 -> ced49c61 (fork PR 1bit-MONSTER/llama.cpp#221) — the HRX backend-ops suite is green at the tip, and the failures it had were named, not hidden.

Before / after

• Before (tip 710c7c23, two runs): 4268/4592 passed, the same 324 failing names both times (the issue's pin cffae5c4 was 4050/4374 with the same 324; the suite has since grown by 218 tests).
• After: 4592/4592 Backend HRX0: OK on two of three full runs. The third was 4591/4592 with one intermittent MUL_MAT(f32, m=1, n=1, k=2048, per=[0,1,2,3], o=1) (ERR 1.19e-2) that passes 5/5 when filtered — reported as a flake, not waived.

The 324, attributed

1. TOPK_MOE, 318 value failures: the only mismatching node is selected_experts — an internal non-contiguous VIEW of the ARGSORT output; HRX reads back garbage ints where CPU has the ids. Comparing the routed weights (the op result) passes at every shape/gating flag; real graphs consume the ids inside GET_ROWS on device. Now an explicit per-backend WAIVER [HRX0] TOPK_MOE: … line (printed once, with the reason); other backends still compare the ids and every backend compares the weights.
2. Two compile-time cases: a kernel bug at expert_count=32 — qwen3_moe_router_top8_f32 assumes experts_per_lane0 in [1,16] but computes expert_count / wave_size (64), so 32 gives 0. The matcher now refuses <64 experts and any count that is not a multiple of the 64-lane wave (this also caught a 288-expert shape whose fused weights were off by 1e-6); small test graphs run the standalone dispatches and pass.
3. DSV4_HC_POST, 4 (identity=0): hip.hc_post is a private HIP add-on dispatch, not in this fork; identity=1 passes both shapes. Explicit named waiver.

Waivers are the only skips, each printed with its reason — nothing is silently skipped. Remaining follow-ups (tracked on engine#1259, not blocking): the add-on's identity=0 path (gpu-kernels repo) and optionally materialising non-contiguous view outputs on HRX, which would remove the TOPK_MOE waiver.

Merge gate

Required context is build; the suite evidence above is from the HRX build on strixhalo and is recorded on engine#1259. registry/architectures.json regenerated (sources: ced49c61, 298/298) and tools/check_pins.py reports 710c7c23c -> ced49c61b is ahead. Upstream pin move with measured behaviour; no RFC-relevant surface.

[github-actions]

Preparing review...