[AMD] Add GLM-5.3-Flash MI30x nightly GSM8K accuracy gate

[michaelzhang-ai]

What

Adds the gfx942 half of the GLM-5.3-Flash nightly GSM8K gate:

• Test: test/registered/amd/accuracy/mi30x/test_glm53_flash_eval_mi30x.py
• Suite: nightly-amd-accuracy-8-gpu-glm53-flash
• Job: nightly-8-gpu-glm53-flash on linux-mi300-8gpu-sglang, with an 18000 s per-file cap

This is split out of #36903 (merged), which added the MI35x gate. It uses the same recipe, eval and 0.92 threshold.

Depends on

#41136. Without its mHC HIP guard, decode graph capture on gfx942 fails with Unresolved call Op(tl.get_lane_idx) (run 36079282524). This PR stays in draft until #41136 lands.

Why

gfx942 does not get the fast paths gfx950 does. mHC runs on the generic path, because AITER mHC is gfx95-only, and nothing else gives that path nightly coverage for this model.

Notes for the reviewer

• MoE runner: the test uses the AITER MoE runner rather than the Triton runner that the recipe names for MI300X. On gfx942 the Triton runner produces sequences that never stop and score 0/64. That happened with both DSA top-k backends, while AITER scored 63/64 in the same job (run 36119287477).
• Budget: the 328 GB checkpoint has taken 2769 to 4143 s to load from this pool's shared cache. The 18000 s cap is deliberately generous so that the full split is kept, which keeps this score comparable to the MI35x one.

Test plan

• All three images on the current head with [AMD] [GLM-5.3-Flash] Restore two HIP fallbacks: clamped-SwiGLU Triton MoE and the fused mHC boundary #41136 merged in, full 1319-question split (run 36798759252, branch amd/glm53-flash-mi30x-validation = this PR's 3143825a63 + [AMD] [GLM-5.3-Flash] Restore two HIP fallbacks: clamped-SwiGLU Triton MoE and the fused mHC boundary #41136's 2796d33002):

  Image	Score	Test wall clock	Weight load	Eval
  rocm10	0.9742 (1285/1319)	2925 s	1139 s	1459 s
  rocm720	0.9712 (1281/1319)	2969 s	921 s	1781 s
  rocm724	0.9735 (1284/1319)	2287 s	716 s	1202 s

  All three pass the 0.92 threshold with no request errors, and each server came up on its first launch. Loads were fast in this run, so it does not exercise the slow-cache case the 9000 s timeout is for.

• The previous run, on a8be4dfab8 (run 36678520753), also passed on all three images: 0.9735 / 0.9720 / 0.9704 on rocm10 / rocm720 / rocm724. There, though, the first server launch on every image timed out at the then 5400 s SERVER_LAUNCH_TIMEOUT while still loading weights, and only the CI's automatic online retry brought the server up, after loads of 4427-4650 s. 3143825a63 raises SERVER_LAUNCH_TIMEOUT to 9000 s and est_time to 11400 s so a load that slow succeeds on the first attempt; the workflow's 18000 s per-file cap already covers that.

• Earlier, on the previous harness: full split on rocm10 with [AMD] [GLM-5.3-Flash] Restore two HIP fallbacks: clamped-SwiGLU Triton MoE and the fused mHC boundary #41136 applied scored 0.9750 (1286/1319), 4419 s wall clock including a 2769 s weight load (run 36232707853).

• The test calls run_sgl_eval directly instead of going through run_combined_tests, because #41280 removed the sgl_eval_thinking parameter the earlier harness relied on. Server arguments and sampling are unchanged.

---

CI States

Latest PR Test (Base): ❌ Run #37208245343
Latest PR Test (Extra): ❌ Run #37208245229
Latest PR Test (AMD ROCm 10): ❌ Run #37208245463