SPIR-V: emit OpFreezeKHR via SPV_KHR_poison_freeze #1074

Without an extension, SPIR-V can't represent freeze. Both back-ends replace a freeze with its operand (a null constant for a frozen undef/poison), which is wrong whenever a poison value reaches the instruction at run time. SPV_KHR_poison_freeze adds a real OpFreezeKHR, and both the Khronos translator and the LLVM back-end support it as of version 23. Since #1073 GPUCompiler no longer strips freeze, so passing extensions="+SPV_KHR_poison_freeze" already makes both back-ends emit it.

Two things have to happen before we can rely on it:

• SPIRV-Tools. SPIRV_Tools_jll 2025.4 doesn't recognize the PoisonFreezeKHR capability (Invalid capability operand: 5156), so the validator, spirv-opt and the disassembler all fail on such modules. The extension landed in SPIRV-Headers in March 2026 (Add SPV_KHR_poison_freeze KhronosGroup/SPIRV-Headers#573), and SPIRV-Tools v2026.3 and v2026.4 bundle headers that include it. That needs a Yggdrasil bump, then a check that the validator accepts OpFreezeKHR and not just the capability.
• Drivers. As far as I can tell from code search, neither IGC (oneAPI.jl, OpenCL.jl on Intel) nor PoCL (OpenCL.jl on CPU) mentions the extension yet, and both back-ends declare it whenever a module contains freeze. Until drivers accept it, it can only be enabled where the device reports it, e.g. from oneAPI.jl or OpenCL.jl based on the device's extension list, not by default in GPUCompiler.

Without the extension, both back-ends turn freeze of a constant undef/poison into a null constant, which is fine because LLVM folds those well before mcgen anyway. The remaining gap is freeze on runtime values, which the back-ends turn into plain copies.