deepseek_v4 accepts VK=1 and COLI_VULKAN=* and silently ignores them

[JustVugg]

Split out of #887, where two people independently set the documented Vulkan variables, watched the GPU stay idle, and reasonably concluded the backend was broken.

COLI_VULKAN / backend_vulkan / coli_vk_ references:
    c/colibri.c      85
    c/kimi_k3.c      23
    c/deepseek_v4.c   0

c/Makefile.deepseek-v4:  no reference to VK or vulkan

So make deepseek-v4 VK=1 produces a byte-identical binary to make deepseek-v4, and COLI_VULKAN=1 COLI_VK_DENSE=1 COLI_VK_ATTN=1 are read by nothing in that engine.

This is a bug independent of whether DeepSeek V4 ever gets a Vulkan backend. Accepting a flag and doing nothing is worse than rejecting it: the user gets no signal, spends their time on driver checks and vulkaninfo, and files a bug about the wrong thing. @BranBushes and @krusherpt both did exactly that.

What it should do

Either the Makefile refuses VK=1 with the same shape of message the ARCH gate already uses —

deepseek-v4 is supported only on x86-64/aarch64 Linux and Windows/MSYS2

— or the engine says once at startup that COLI_VULKAN is set and unsupported for this architecture, and continues on CPU.

The second is probably better: the variable may be exported in a shell profile for GLM and inherited by a DeepSeek run without the user intending anything by it.

The same shape, a fourth time

This is the recurring defect in this repo, and it is worth naming rather than fixing case by case:

OMP_NUM_THREADS	reached glm only, not its four siblings (#805)
RAM_GB	10 references in colibri.c, 0 in kimi_k3.c (#855)
model_arch()	four families of five; the banner named the fifth (#879)
COLI_VULKAN	two engines of five, silently inert in a third (here)

Each was found by a user, not by us. A registry of the environment variables with a per-engine support matrix would catch this class at build time — which is what #800 is reaching for, and an argument for finishing it.

Refs #887

[JustVugg]

Partly overtaken and worth closing rather than leaving as a standing complaint.

#904 (@Blakeolson21) started the per-engine environment table in docs/ENVIRONMENT.md — the thing this issue was really asking for. That is the durable fix: a place where COLI_VULKAN being read by two engines of five is visible before someone spends an evening on vulkaninfo.

The narrower ask — deepseek_v4 accepting VK=1 and COLI_VULKAN=* and doing nothing — is still true and still worth a guard. But it belongs to whoever adds Vulkan to that engine, or to #800's environment registry, rather than sitting here as a separate task nobody owns.

Reopening is right if either of those stalls and a user hits it again. @BranBushes and @krusherpt both did, which is why it was filed.