sm-scoped transfer accepted in host code: unfoldable gpu ops in func.func @main fail LLVM translation

The emittable gate requires the destination space to declare scope: sm, but not that the transfer sits inside a spawn on for the machine that owns the edge — and selection deliberately accepts a single unambiguous candidate at host-driven sites (a49e583b/51aa61dc, which is right for host edges).

So transfer(ad, Memory::SMEM) written directly in main is accepted, and the splice puts gpu.block_dim / gpu.thread_id / gpu.barrier into func.func @main. Even with no user lowering, TransferOpLowering creates its C3 gpu.barrier for any scope: sm transfer including one in a host function.

The host-side fold in ConvertVxToLLVMPass walks only vx::KernelOp bodies, so these ops are never folded, and the host ConversionTarget has no gpu-dialect story — compilation fails downstream at LLVM translation on a program the checker accepted.

Loud, not silent, which is why this is filed rather than urgent: the failure is a hard error, not a wrong answer. But the error names an MLIR op, not the programmer's mistake, and the mistake is a real one worth diagnosing directly: an sm-scoped transfer outside any kernel has no lanes to cooperate.

Suggested fix: require kernel context for sm-destination emission (and for the builtin's C3 barrier), with a diagnostic saying an sm transfer must occur inside a spawn on for the machine that declares the edge.

Found by the memalg codegen review (emission pass).

Start with TransferOpLowering and ConvertVxToLLVMPass, especially the host-side fold that walks vx::KernelOp bodies, then inspect selection and emittable-gate handling for sm-destination transfers. Done means an sm-scoped transfer outside the owning machine's spawn on is rejected with a direct diagnostic, and host functions no longer receive gpu.block_dim, gpu.thread_id, or gpu.barrier ops.