arm: NEON + i8mm vec_dot for PTQ1_0

[karusrus]

Overview

Follow-up to #265, which dropped its PTQ1_0 NEON kernel and asked for a validated one. This adds a NEON vec_dot for PTQ1_0 x Q8_0 on ARM, with an i8mm path for prompt processing.

• Trits are decoded in 8-bit lanes: ((q + (q >> 1)) >> 1) >> 6 equals (3q) >> 8 for every byte value (checked for all 256), so there is no widening to u16. One block becomes eight int8x16 vectors in element order.
• Each 32-wide Q8_0 sub-block is reduced with sdot and accumulated in float32x4; one horizontal add per row.
• With __ARM_FEATURE_MATMUL_INT8, PTQ1_0 uses nrows = 2 and computes a 2x2 tile with SMMLA, so every decoded trit vector is used for two activation columns.

Results

Snapdragon 7 Gen 4 (Cortex-A720/A520, dotprod + i8mm), Ternary Bonsai 2 27B PTQ1_0, CPU only, -t 5, runs alternated:

build	pp64 t/s	tg16 t/s
generic	1.22	1.09
this PR	2.33	1.31

test-backend-ops perf, MUL_MAT m=4096 k=14336: n=1 65.9 GFLOPS, n=512 153.4 GFLOPS.

Tests: with #265 merged on top, test-quantize-fns passes, including its exact packed ternary vec_dot check ("ternary packed dot products: ok (0 failures)"). That check uses nrc == 1. The nrc == 2 (i8mm) path was checked end to end: greedy 24-token output on the 27B is byte-identical to the generic path. The file also builds for armv7a (NEON, no i8mm).

Additional information

• Follow-up to arm: NEON vec_dot for PQ2_0 #265. cc @kiljoy001 @bri-prism
• Conflicts with arm: NEON vec_dot for PQ2_0 #265 in one line of arch-fallback.h (neighbouring alias lines). I will rebase after arm: NEON vec_dot for PQ2_0 #265 lands.
• The dotprod path (the first two points in the overview) does not need i8mm, so it can be checked on RK3588 / Cortex-A76 too. Only the nrc == 2 path needs i8mm.

Requirements

• I have read and agree with the contributing guidelines
• AI usage disclosure: YES. The kernel was written with Claude Code. I built, tested and measured it on my device.

[bri-prism]

@karusrus @kiljoy001, thanks for already working this out on #265. Both kernels test bit-exact on an M5 Pro, including the i8mm two-row path. Our plan is to merge #265 first and then #290, which only needs its arch-fallback.h alias lines dropped when rebasing.

[karusrus]

Thanks @bri-prism, sounds good. Once #265 is in, I'll rebase this on master and drop the arch-fallback.h alias lines: the ARM PTQ1_0 alias from #265 goes away, since this PR adds the NEON kernel, and the PQ2_0 x Q8_K alias stays. If it's easier for you to do that while merging, that works too.

[karusrus]

@bri-prism rebased on prism now that #265 is in. Both ARM aliases in arch-fallback.h are gone: the PTQ1_0 one because this PR adds the NEON kernel, and the PQ2_0 x Q8_K one because #265 brought a NEON kernel for it. I said earlier that the second alias would stay; that was before #265 landed in its final form. Nothing else changed.

test-quantize-fns passes on arm64 (NEON + dotprod). The i8mm path is the same code you tested on the M5 Pro.