d27639e71 re-added an unguarded #include <unistd.h> to test_qwen3_dflash2_gguf, which #1581 had already fixed through the process_id seam

[localai-bot]

d27639e71 re-added an unguarded #include <unistd.h> to a file that had
already been fixed through the process_id seam, so the include is both
redundant and hostile to MSVC.

What happened

Three commits, in order:

1. 5702d8f83 introduced a direct ::getpid() call in
   tests/vllm/models/test_qwen3_dflash2_gguf.cpp, which reddened
   build-newest-gcc (gcc 16 no longer pulls <unistd.h> in transitively).
   Reported as #1575 and
   #1565.
2. 13548db8f (PR fix(SPEC-DFLASH2): build-newest-gcc has been red since W5, because the GGUF test bypassed the process_id seam (#1575) #1581) fixed it correctly: the direct call was replaced
   by vllm_test::ProcessId() and #include "support/process_id.h", which is
   the tree's one portable spelling.
3. d27639e71 (PR fix(BACKEND-TENSTORRENT-HOST-FREE-FORWARD): captured decode degenerate at the first KV block boundary (#1476) #1498, merged while landing external contributions) then
   added #include <unistd.h> at line 62 of the same file. That change was
   authored against the pre-fix(SPEC-DFLASH2): build-newest-gcc has been red since W5, because the GGUF test bypassed the process_id seam (#1575) #1581 tree, where it was the right fix. By the time
   it landed, fix(SPEC-DFLASH2): build-newest-gcc has been red since W5, because the GGUF test bypassed the process_id seam (#1575) #1581 had already removed the call it was there to support.

Why it is a defect and not just noise

The file now contains no ::getpid call, so the include supports nothing.
tests/support/process_id.h states the rule it breaks, in its own header
comment:

::getpid() is POSIX, and its declaration lives in <unistd.h>, which MSVC
does not ship at all. So the obvious spelling does not fail on Windows — it
does not COMPILE, and it takes both windows-msvc-* lanes down with it.

That is the #603 shape, an
instance of the #503 class. It
does not show as a NEW red because both windows-msvc-* lanes are already
baseline-red and never run on main at all, which is exactly the condition
that let it through.

The header also predicts this recurrence: "That was fixed once in three files
and came back in five more."

Fix

Delete the one line. No call needs it, and support/process_id.h is already
included at line 68.

Found while merging external contributor pull requests; fixed in the same flow.