[CuTe DSL] Reject direct kernel compilation with a user error (issue #3429)

[XFDG]

Summary

• preserve whether a CuTe DSL wrapper was created by @cute.jit or @cute.kernel
• reject a kernel passed directly to cute.compile before host-wrapper lowering
• emit a structured user diagnostic that points to the supported @cute.jit launcher pattern
• add a regression test that verifies the error code and ensures the message is not reported as an internal error

Problem

cute.compile builds an executable host wrapper and expects a function decorated with @cute.jit. Passing an @cute.kernel function directly currently falls through to host-wrapper lowering. For the FP32-to-FP8 example in #3429, this reaches invalid scalar conversion IR and is eventually reported as an internal compiler error, even though the actionable problem is the unsupported compile entry point.

The wrapper already closes over the internal executor name, but that distinction is lost when CompileCallable unwraps the decorated function. This change records the executor name on the wrapper and checks it before unwrapping.

Validation

• NVIDIA B200 (SM100), CUDA 13.1: reproduced the original cute.compile(kernel, 0.0) failure as an MLIR verification/internal error.
• NVIDIA B200 compatibility probe: the same call with the entry guard fails immediately with the @cute.jit launcher guidance and contains no Internal Error.
• python3 -m py_compile passes for all changed Python files.
• Ruff severe-rule checks pass for all changed files; full lint and format checks pass for the new regression test.
• git diff --check passes.

The B200 runtime probe used the node's ABI-compatible CuTe DSL 4.3.5 package with the same entry guard applied in an isolated GPFS overlay; the submitted current-main files were validated statically, and the added regression test exercises the guard before code generation.

Fixes #3429