build: gcc 15 hits the same -Warray-bounds false positive, so widen the demotion guard

[joral]

The guard added the -Wno-error=array-bounds escape hatch for GCC >= 16 only, and
its comment asserted that everything at or below 15 still fails the build on a
real out-of-bounds. gcc 15.2.0 reproduces the same false-positive class from the
other libstdc++ container: std::vector's inlined copy-construct plus
_M_allocate, reported at ltx2_samplers.cpp:161,163 against a bound of
float[2305843009213693951]. That bound is SIZE_MAX/4, the allocator's
unconstrained size range rather than a real object, which is the inlining
attribution the guard's own comment already documents for _M_release. The
subscripts are sigmas.back() on a copy of a container that VT_CHECK proves holds
at least two elements three lines above, and GCC does not propagate that
throwing check through the inlined copy.

main therefore did not build on gcc 15.x at all, stopping at 146/1552, and no CI
lane covers the release: the matrix is gcc 13 on every ordinary Linux lane and
gcc 16 in build-newest-gcc, which the guard already exempts, so the failure sits
exactly between the two points. gcc 15 is the current toolchain on Arch, NixOS
unstable and Fedora 42.

Measured on 4ee5f4a with gcc 15.2.0: the translation unit is exit 1 with two
-Werror=array-bounds= errors, and exit 0 with the same two as warnings once the
guard applies, so the diagnostic stays visible exactly as intended.
scripts/agent-preflight.sh fails the identical 10 gates before and after.

Whether CI should also cover gcc 14 and 15 is a separate question and is
deliberately not bundled here, because the widened guard already prevents this
defect recurring and a lane would guard a different class.

Closes #1292

FOLLOWING_AGENTS_PROTOCOL

Following-Agents-Protocol: true
AI-Assisted: true
Assisted-by: Claude:claude-sonnet-5 [Claude Code]

[localai-org-maint-bot]

The GCC 15 diagnosis and version-gate change look correct, but this branch is currently conflicting with main. Please rebase it onto current main; after that, the focused GCC 15 red/green evidence should make this ready for a merge ping.

[joral]

Rebased as requested. The remaining red does not come from this change.

I rebased onto c8d926ea8. The conflict cleared and the pull request reached MERGEABLE. Main then advanced to 5870cb2b, and the branch returned to CONFLICTING. Main stands at aee6c48d6 now.

Facts:

• record(BACKEND-ROCM): index the decode profile, which refutes the transfer hypothesis #1295, a separate pull request of mine, adds one line to .agents/issue-index.md and nothing else. It fails build-test-cpu on test_minimax_music3_ar, test_ltx2_video, test_ltx2_text_encoder, test_muse_glimmer_text, and test_muse_glimmer_text_fallback.
• Pull requests from other authors fail the same job. record(A2-Q1): the moved token is not yet shown to be a defect, and the measurement that would decide it is blocked (#1388, #1431) #1432 fails on test_ltx2_video. feat(A2-Q2b): lm_head reaches the device on NVFP4, and the seam stops handing out an address-keyed cache #1415 fails on test_nemotron_h_paged_forward.
• build-test-cpu runs on a pull request only, so main holds no recorded result for it.
• On this pull request, build-newest-gcc passes, which is the job this change repairs.

Inference: a one-line Markdown addition cannot fail five model tests. The red comes from the base.

The same file explains the conflict. GitHub does not apply the merge=union driver when it computes mergeability, so each merge returns every other open pull request to CONFLICTING. Main moves faster than one ci cycle, which cuda-fat-build alone extends to 1 hour 40 minutes. I can rebase again on request, but I am worried the same result would follow.