Hardware e4m3 in the texture tails: enc0 tail and dec0 head

On the gfx12 native-FP8 path the enc0 tail and the dec0 head encode their results with v_cvt_pk_fp8_f32 on the f32 copies of the f16 values (e4m3x4_f32 in tex_common.h) instead of ZLUDA's integer e4m3x2. The clamps keep the conversion in range: +-2pi for enc0 (the f16 bound hi[0], same in f32) and +-448 for dec0, both as a median of three, where a NaN gives the lower bound. The codes equal e4m3x2 for every non-NaN f16, checked over all 65536 patterns on an RX 9070 XT; a NaN in dec0 now encodes as -448 instead of the NaN code. Harness frames are byte-identical in both sets (LDR and HDR, motion vectors at render and display resolution). dec0: 0.21 -> 0.15 ms at 1280x720 render and 0.74 -> 0.53 ms at 2560x1440; enc0 changes by 1-2% (its time is ZLUDA's compile of the feature code). -DD4R_TEX_SOFT_E4M3 (D4R_TEX_CFLAGS) keeps e4m3x2.

kernels/tex/dec0_head.hip

@@ -87,12 +87,21 @@ DEV void d4r_dec0_head(uint32_t smem, uint64_t wp, uint64_t inp, uint32_t dimx,
             for (int i = 0; i < 8; ++i)
                 cf[i] = (float)acc[i];
         }
+#ifdef D4R_TEX_HW_E4M3
+        // cf holds the f16 results as f32. A NaN becomes -448 here (e4m3x2: the NaN code).
+#pragma unroll
+        for (int i = 0; i < 8; ++i)
+            cf[i] = __builtin_amdgcn_fmed3f(cf[i], -448.0f, 448.0f);
+        E[p][0] = e4m3x4_f32(cf[0], cf[1], cf[2], cf[3]);
+        E[p][1] = e4m3x4_f32(cf[4], cf[5], cf[6], cf[7]);
+#else
         uint32_t codes[4];
 #pragma unroll
         for (int k = 0; k < 4; ++k)
             codes[k] = e4m3x2(pack2(acc[2 * k], acc[2 * k + 1]));
         E[p][0] = codes[0] | (codes[1] << 16);
         E[p][1] = codes[2] | (codes[3] << 16);
+#endif
     }
 
     // staging (layout as below): this lane holds tiles 4G + hf and 4G + 2 + hf (channels 16p + 8hf ..), so it