arm64: honor f16 unicast operand in mmm_f32 32x1/32x3 add_unicast

[czoli1976]

The arm64simd mmm_f32_32x1 / mmm_f32_32x3 and x86_64 fma_mmm_f32_32x1 / fma_mmm_f32_32x3 kernels declare store(f16) but their .add_unicast path never handled an f16 operand: it ignored item_size and always loaded the unicast operand as f32, so a fused f16 AddUnicast (e.g. a residual Add folded into a native q40 GEMV) was read at the wrong width and could saturate to inf.

Each kernel gains the missing item_size == 2 branch that converts the operand before the add — fcvtl on arm64, vcvtph2ps on x86_64 — mirroring the existing store_f16 path (both the contiguous and strided variants).

Tests:

add_unicast_dt (store-dtype-gated): operand dtype = the kernel's declared store dtype, covering the f16-into-f32 case for every f16-storing kernel. Fails on all four kernels without the fix, passes with it.
add_unicast_pattern (new): reads the operand across the col-major, row-major and arbitrary StoreLayouts, so both the contiguous and strided add_unicast load paths are checked for every store dtype.
Full tract-linalg suite green. Qwen2.5-7B-Instruct-q40ef16 decodes correctly on arm64 CPU (previously NaN); on x86_64 CPU the same kernels carried the latent bug (the add_unicast_dt test fails there without the fix) and the model continues to decode correctly.

Root-caused from #2475; complements #2477 (which gates off the fusion) by making the kernels themselves safe.

🍍

[czoli1976]

@JulienBalianSonos

[kali]

ok ! bug it is.

[kali]

These are the only two kernels impacted ?

[kali]

These are the only two kernels impacted ?

nope.

[kali]

#2477 is superseded, right ?

[JulienBalianSonos]

@czoli1976 Nice finding, congrats! I will let the review go to @kali, as I am not in my comfort zone with assembly, but it 'sounds' like a legit fix.

[czoli1976]

It appears so

[github-actions]

⚠️ Bench vs main — no speed regressions · 2 secondary regression(s)

Reference: 2026-07-20 morning nightly run (0d old) · full report → run

Speed — evaltime · prefill · decode

no inference-speed regressions

⚠️ 2 secondary regression(s)

Δ	metric	device	main → PR
⚠️ +15.5%	en_tdnn_pyt_15M load · pulse_120ms	apple-m1-max	84 ms → 97 ms
⚠️ +13.3%	en_tdnn_pyt_15M load+optimize · pulse_120ms	apple-m1-max	98 ms → 111 ms

[kali]

@czoli1976 are you in a position to address the fma ones, or should I do it ?

[czoli1976]

@czoli1976 are you in a position to address the fma ones, or should I do it ?

let me look

[github-actions]

⚠️ Bench vs main — no speed regressions · 2 secondary regression(s)

Reference: 2026-07-20 morning nightly run (0d old) · full report → run

Speed — evaltime · prefill · decode

no inference-speed regressions

⚠️ 2 secondary regression(s)

Δ	metric	device	main → PR
⚠️ +15.5%	en_tdnn_pyt_15M load · pulse_120ms	apple-m1-max	84 ms → 97 ms
⚠️ +13.3%	en_tdnn_pyt_15M load+optimize · pulse_120ms	apple-m1-max	98 ms → 111 ms