check-device-leakage's kcuda bucket is a token grep: minimax_h3_video.cpp hardcodes CUDA via static_cast<vt::DeviceType>(1) and counts as 0

[localai-bot]

scripts/check-device-leakage.py counts the kcuda bucket with a pure token
grep (:78):

RE_KCUDA = re.compile(r"\bkCUDA\b")

so a site that reaches the same device WITHOUT spelling the token is invisible to
the ratchet. src/vllm/multimodal/minimax_h3_video.cpp:221-226 is exactly that
site, in the device-agnostic shared layer the checker exists to protect:

vt::DeviceType MiniMaxH3VideoDeviceType(int32_t device) {
  if (device != 0 && device != 1) {
    throw std::runtime_error("minimax_h3 video: device must be 0 (cpu) or 1 (cuda)");
  }
  return static_cast<vt::DeviceType>(device);
}

It hardcodes CUDA — its own error message says so — by relying on
kCUDA == 1 in the DeviceType enum (include/vt/device.h:16-29). It is MORE
brittle than the DeviceType::kCUDA the ratchet does catch, because it is also
silently wrong the day the enum is reordered, and kTENSTORRENT was appended to
that enum as recently as the Tenstorrent backend row. It contributes 0 to
kcuda, so kcuda == 0 on main reads as "no CUDA reference in the shared
layer" when there is one.

This is the SIBLING lane of src/vllm/multimodal/ltx2_video.cpp, whose two
honest DeviceType::kCUDA sites are what put main red on this ratchet (#553).
Found while reviewing that repair: the repair is correct and routes through
vllm::platforms::CurrentPlatform(), but the gate it turns green is weaker than
the number suggests, and the two files should reach the device the same way.

Behavior is correct on a CUDA box today; this is gate strength plus a latent
enum-ordering hazard, in the shape of #469.

Two things are owed, and they are separable:

1. MiniMaxH3VideoDeviceType should ask the platform seam
   (CurrentPlatform().device_type()) exactly as Ltx2VideoEngine::Load now
   does, so device = 1 means "the accelerator this process is on" on both video
   lanes rather than "enum value 1".
2. The ratchet should be able to see a cast to vt::DeviceType. A
   static_cast<vt::DeviceType>(<expr>) in a SCAN_ROOTS file is either the
   platform leg (allowlist it with a reason) or a DSR, and today it is neither
   counted nor refused. Changing the checker's semantics needs a spec and a
   red-before mutation per AGENTS.md.