fix: say why Int4GroupwiseGemmPluginV2 cannot execute when its kernels are absent

[filipemartinsubrobotics]

Fixes #210.

ENABLE_CUTE_DSL defaults to fmha, which omits int4_fp16_gemm. An INT4 model built
that way compiles Int4GroupwiseGemmPluginV2 with CUTE_DSL_INT4_FP16_GEMM_ENABLED
undefined, so enqueue() returns -1 from the #else branch with no message.

Why this is hard to work back from

Nothing before inference fails. The CuTe DSL archive builds, the plugin compiles and
registers, the ONNX graph parses, the engine builds and serialises, and the runtime loads
it and allocates. The first symptom is at generation:

[E] Error Code: 2: int4_groupwise_gemm_v2_4: Failed to enqueue status -1
[E] IExecutionContext::enqueueV3: Error Code 1: Myelin ([immediate.cpp:exec:156]
    Custom layer callback with tactic id '..._706246428453888_0' failed.
    In executeMyelinGraph at runtime/myelin/runner.cpp:778)
[E] [inline single-rank] handleRequest failed: Failed to execute base model for prefill step.

That names a tactic id and a Myelin callback, so it reads as a kernel problem. It is a
cmake default. I chased the kernel first — checked the archive metadata (both groups
present, 95 variants), the weights (byte-identical to a known-good export), the plugin
attributes, the graph, the runtime config — before instrumenting
cuteDslInt4GemmLoadModules() and getting no output at all, which was what finally
showed the whole block had been compiled out rather than failing inside.

The change

Log once from that branch, naming the flag:

Int4GroupwiseGemmPluginV2: this build has no CuTe DSL INT4 kernels, so the plugin cannot
execute. Reconfigure with -DENABLE_CUTE_DSL="fmha;int4_fp16_gemm" -- the default is
"fmha" alone, which omits the INT4 GEMM group -- and rebuild.

std::call_once keeps it off the per-enqueue path. <mutex> is already included and
LOG_ERROR is already used in this file, so no new includes. Behaviour is unchanged —
the branch still returns -1.

Syntax-checked both ways, with the macro defined and undefined.

An alternative, if you would rather have it earlier

cmake knows both whether the INT4 plugin is being built and whether int4_fp16_gemm is in
ENABLE_CUTE_DSL, so a configure-time warning would catch this before a single kernel
compiles. That touches the build system rather than one plugin, so I have kept this to the
smaller change — happy to move it if you prefer.

---

Found while bringing up an INT4-AWQ Cosmos3-Edge checkpoint on a DGX B300 during the
NVIDIA / OpenHackathons / Oracle Open Models Codefest 2026, for an offline-first
search-and-rescue robotics entry (Team UBR Stack). The production target is a Jetson Orin
Nano; the B300 is a bench machine used for evaluation.