hrx: fence both global and LDS at the decode-split barriers (engine#123 follow-up)

[bong-water-water-bong]

Follow-up to #28 (engine#123 / ggml-org#140).

Two changes

1. Pack sites: fence LDS again, not only global. A Loom kernel.barrier fences only the memory space it names (loom docs, Synchronization names both rendezvous and memory). #28 replaced the barrier<workgroup> before pack_completed_q8 with barrier<global>. That orders the reduce's global output stores, but it drops the LDS fence the cooperative and multipass reducers had for their staging buffers. All 5 pack sites now use both, i.e. HIP __syncthreads semantics:

kernel.barrier<global> scope(workgroup) ordering(acq_rel)
kernel.barrier<workgroup> scope(workgroup) ordering(acq_rel)

2. Standalone two-dispatch reducer: same bug as #28, now fixed. In ggml_flash_attention_decode_split_reduce_f32 and its qwen3_moe copy, wave 0 rewrites partial_max in global memory with the exp scales. Every wave then reads it back after a barrier<workgroup> only. Wave 0 had read those same lines during the max pass, so other waves could hit stale GL1/L0 copies (the block maxima instead of the scales). This kernel is not dispatched today; it gets the <global> barrier too.

Compiled ISA (gfx1151)

• Pack handoff, from the JIT dumps of the real engine run: direct (short ctx), cooperative (~600 tokens) and multipass (30B, 2113 tokens) all compile to vmcnt(0), vscnt(0), s_barrier, buffer_gl1_inv, buffer_gl0_inv, s_barrier, then the pack global_load_b128.
• Standalone reducer, via loom-compile: before, 2 barriers and no invalidates; after, 3 barriers with buffer_gl1_inv + buffer_gl0_inv.

Tests

	result
Qwen3-0.6B, 24-token greedy, with a process forcing KFD queue evictions	0 of 118 divergent (only the warm-up request differs)
Qwen3-Coder-30B, 2113-token prompt, GGML_HRX_FA_PARTIAL_ALIGN=256, evictions	8 of 8 correct, 0 NaN
Standalone reducer, ad-hoc on-device check case run with iree-test-loom (scale 1 vs stale max 0; not committed), 2000 runs before the fix	0 failures, so the race is not reproducible there; the fix rests on the ISA and the memory model

Decode speed vs #28 is within run-to-run noise on this shared box (2 interleaved rounds):

tok/s	#28	this PR
0.6B d0	296–300	276–287
0.6B d1000	199–207	204–215
30B d2100	58.9–62.0	57.0–60.6

🤖 Generated with Claude Code