VLLM_CPP_TRITON should default ON (vendored cubins need no Python); today's opt-in default silently benched the hand path

[localai-bot]

VLLM_CPP_TRITON defaults to OFF (cmake/TritonAOT.cmake:57), so the vendored
Triton AOT GDN kernels are opt-in. They should be on by default; a user who
does not want them passes -DVLLM_CPP_TRITON=OFF.

Why the current default is wrong

The option's own help string says it: "CUDA-only; no Python needed". The
vendored artifacts are pre-generated cubins embedded in plain C launchers
(src/vt/cuda/triton_aot_vendored/<arch>/), consumed with only a C compiler —
no Python, no Triton, no ptxas, no GPU at build time. There is no dependency
that an opt-in default protects against.

Meanwhile the default is an active measurement hazard. A bench or dev build that
simply omits the flag runs the hand-written WMMA path while its recipe implies
otherwise. That has already happened here: one NVFP4 sweep was recorded on a
build that omitted -DVLLM_CPP_TRITON=ON, against kernels the shipped CUDA
release would never execute.

Note the release pipeline is already correct — tests/scripts/test_release_accelerator_metadata.py:57
asserts "ON" if cuda else "OFF". So the shipped CUDA binary has these kernels
and only hand-rolled builds do not, which is precisely backwards from where the
safe default belongs.

Why it is not a one-line flip

Three configurations must keep resolving OFF, and a blanket ON would turn two
of them into configure-time failures:

1. Multi-arch (fat) CUDA builds. A vendored cubin is single-arch;
   _triton_aot_arch_name (cmake/TritonAOT.cmake:110-127) raises
   FATAL_ERROR for VLLM_CPP_CUDA_ARCHITECTURES="120a;121a". Correct: the
   driver refuses a cubin built for another SM.
2. Non-CUDA backends (CPU, Metal/MSL, Vulkan, ROCm). The tree is CUDA-only.
3. A CUDA arch with no vendored tree. Configuration currently fails with
   regeneration instructions; accepting a default must not do that.

Proposed behavior

Compute the default instead of hardcoding it: ON when CUDA is enabled and
the build is single-arch and a vendored tree exists for that arch; OFF
otherwise, with a status line naming which condition declined it. An explicit
-DVLLM_CPP_TRITON=ON must keep failing loudly on a fat build or a missing tree —
asking for something impossible should still be an error; only the default may
degrade quietly.

Also owed in the same change: docs/USAGE.md:134 and docs/STATUS.md:1345-1348
describe the opt-in default and need updating, and the release-metadata
expectations must be re-derived rather than edited to match.

Separately: are they actually dispatched?

Building is not using. TryTritonChunkO (src/vt/cuda/cuda_gdn.cu:4903-4917)
has six silent bail-outs to the hand path — device availability, the
VT_GDN_CHUNKO_TRITON toggle, dk/dv/hk_n shape, hv_n not in {48,32}, a null
chunk_indices, and a scale that is not exactly Dk^-0.5. None warn. There are
launch counters (GdnDebugCounters, chunk_o_{f32,bf16}_launches) that can
prove which path ran on the gate models; that evidence should be captured and
recorded rather than assumed.