fix(BACKEND-TENSTORRENT-QWEN35): guard the empty-vector fwrite GCC 15 flags under -Werror=nonnull

[joral]

A fresh CPU build of main fails under GCC 15.2.0 with -Werror=nonnull:

src/vllm/model_executor/models/qwen3_5.cpp:4019:24: error: argument 1 null
where non-null expected [-Werror=nonnull]
            std::fwrite(vec.data(), 4, vec.size(), f2);

vec (std::vector<float>, from the Tenstorrent DebugDeviceReadbackF32
debug-dump path added in #1715) may be empty, in which case data() may
return nullptr; fwrite's first parameter is declared nonnull. A size-0
fwrite on a null pointer is well-defined by the C standard, but the
attribute makes the call itself UB by the letter of the standard, which GCC
15 now flags statically regardless of the runtime size.

Guards the write on !vec.empty(), mirroring the pattern the raw-bytes write
three lines above already uses for its own file handle. Debug-only code path
(gated behind the call == 0 / qdir dump condition), so there is no
behavior to preserve beyond skipping a write with nothing to write — already
true logically, now provable to the compiler.

Verified with a single-file targeted rebuild (object file removed, rebuilt
alone) on the same toolchain that reproduced the error: compiles clean.

Found while building main fresh for an unrelated row (#1934); filed and
fixed in flow as #2021 since it blocks every downstream CPU build regardless
of what else changed.

FOLLOWING_AGENTS_PROTOCOL

Following-Agents-Protocol: true
AI-Assisted: true
Assisted-by: AGENT:claude-sonnet-5 [claude-code]

[localai-org-maint-bot]

@mudler This is good to merge. The one-line runtime guard is the correct portable fix for GCC 15 treating a zero-count fwrite(nullptr, ...) as a nonnull violation, and it preserves the debug-dump behavior for every non-empty readback. The branch is mergeable; the two Windows reds are the repository-wide baseline failures tracked in #1979.