🚨 fix(ggml-cuda): backport the block_reduce shared-memory race fix (llama.cpp #26385)

[ykhrustalev]

Backport of ggml-org/llama.cpp#26385, which fixes a shared-memory race in ggml-cuda kernels that call block_reduce twice.

Problem

• block_reduce writes each warp's partial to shared memory, syncs once and reads the partials back, with no barrier after the read. A kernel that reduces twice through one buffer lets a warp that is ahead overwrite partials another warp is still reading
• soft_max_f32 reduces the row maximum and then the sum that way, so a slow warp can take a partial sum for the maximum. group_norm_f32 and the cooperative single-row softmax do the same
• It showed with lfm2_audio: two sessions in one process sometimes gave different bytes for the same request, while each alone was bit-exact. The encoder's attention softmax has rows over 32 positions, which take several warps. compute-sanitizer racecheck reports the hazards on main with one session too
• Not specific to lfm2_audio: on the CUDA backend, and in the HIP build of the same sources, any model with a softmax row over 32 or a group norm over groups of 1024 or more elements is exposed

What this PR changes

• Upstream's diff, unchanged: soft_max_f32 syncs between its two reductions when the block has more than one warp; group_norm_f32 gives its second reduction its own 32 floats; the cooperative softmax gets separate buffers for its maximum and its sum; block_reduce gains a comment stating the contract
• Adaptations: none to the code. The common.cuh and norm.cu hunks apply at other line offsets (norm.cu carries audio.cpp's channel RMS norm kernels), and the vendored files keep their CRLF line endings
• The other block_reduce callers (norm, rms_norm, the channel RMS norm, l2_norm, sum_rows and mean) reduce once per kernel, and convrot-linear's own reduction ends with a barrier, so none needs a change

Testing
A10, CUDA 12.8, main (75d0294) against this branch (the HIP build, which compiles the same sources, was not built or run):

• racecheck, encoder over a 99-position JP question: main 484704 errors, all in soft_max_f32; here none. A single-turn S2S request cut at 60 tokens, every kernel checked: main 1303436 errors; here none
• ggml's test-backend-ops, built from the vendored source against the same ggml (the project does not build it): SOFT_MAX, GROUP_NORM, NORM, RMS_NORM, L2_NORM, SUM_ROWS and MEAN pass on both. Under racecheck's timing main fails 83 of 212 SOFT_MAX cases (the three cooperative ones among them) and both GROUP_NORM cases; this branch passes all, with no hazard
• The four CUDA unit tests, lfm2_audio_cuda_test among them, pass on both
• One session per process, EN and JP F16: ASR offline, seeded TTS and S2S offline and streamed (36 requests per run): all 82 output files byte-identical to main, in two runs each
• Under memcheck's timing, main's encoder output differs in 9 of 9 repeats and a single-turn S2S reply cut at 60 tokens in 5 of 5; this branch's in none
• Two C API sessions in one process, running multi-turn S2S from a branch not yet merged: with this commit 0 of 159 turns differ from the session alone; without any fix 1 of 162 differed, too rare on an idle machine to show the fix by itself. racecheck over a turn with history, limited to the softmax, norm and row-reduction kernels: 466172 errors without any fix, none with this commit

[0xShug0]

@ykhrustalev This may take a little longer. For ggml changes, I need to understand the problem, check the solution, and run regression tests. Sometimes there could be a simpler solution with low regression risk (e.g., #542)

[0xShug0]

@ykhrustalev Thanks, PR merged! No observable performance impact in my tests. I was initially concerned about flash attention, but it bypasses the modified standalone softmax kernel because softmax is fused into the attention kernel.