fix(build): repair the GCC 15 -Werror CPU build, one in code and one scoped

[richiejp]

GCC 15.2.0 rejects two translation units that older compilers accept, so the
CPU build cannot complete on a newer-toolchain host. Both are correct code the
optimizer mis-analyses after inlining. A keep-going build enumerated the whole
surface first: these two, and only these two, out of 731 targets.

hunyuan_a13b.cpp assigned a one-element std::vector from an
initializer_list, which routes through _M_insert_range -> _M_copy_aligned,
where GCC 15 reports a false -Warray-bounds against the bit-packing word copy.
assign(1, true) is the same operation on a different libstdc++ path and needs
no suppression at all, so -Werror keeps its full strength there.

chat_template.cpp draws -Wfree-nonheap-object from inside the vendored minja
parser, so that one demotes exactly that diagnostic, on exactly that unit, for
GNU compilers only. third_party/ is already a SYSTEM include, but that covers
front-end diagnostics only: this one is raised by the optimizer after inlining
and attributed to the translation unit rather than the header, so -isystem
cannot reach it. Ordered after vllm_cpp_set_warnings so the target-level
-Werror cannot re-promote it, which is the ordering lesson from the MLX header
exception.

Pre-existing rather than rebase damage: the identical failure reproduces from a
clean worktree at bfd51fb. CI does not cover it, because ubuntu-latest ships
an older GCC that raises neither diagnostic.

Benchmarked rather than declared not-applicable. The 4B lever was re-run
against the pinned oracle (vLLM 0.23.1rc1.dev1511+g555967922, built from source
at the parity pin) across the 217-commit rebase plus this repair: 0.9980x total
throughput (was 0.9972x on 2026-07-29), TTFT 0.7674x PASS, TPOT 1.1243x still
the one failing axis, peak PSS 2.147 against 7.621 GiB. Output is BIT-IDENTICAL
to the previous series, 128/128 per arm, and agreement with vLLM is unchanged
at 89/128. The 0.0008x ratio move is the denominator (the oracle came in 0.06%
slower while we moved +0.017%), so it is a null result, not an improvement.
Three interleaved repetitions per arm under one flock, all 18 legs at 0% GPU
utilization before starting, clean CUDA rebuild 899/899.

CPU tier: 340/340 targets build, suite 329/331. The two failures are
pre-existing host-environment issues this repair merely made reachable, since
the suite could not be built here at all before: PYTHONHASHSEED=0 exported by
the nix dev shell, and a hardcoded /usr/bin/true that does not exist on NixOS.
Both recorded as open host-portability gaps.

FOLLOWING_AGENTS_PROTOCOL
Assisted-by: Claude Code:claude-opus-5 [ClaudeCode]

[localai-org-maint-bot]

This needs a rebase before it can be shepherded: the branch is now conflicting with current main (16 commits behind), and its ASan/UBSan lane fails during the build while current main CI is green. The archived job log is no longer retrievable from Actions, so please rebase first and let the sanitizer lane produce a fresh result; if it remains red, the fresh compiler output should make the remaining source-level issue actionable.