Use the current SIMD target's width for the transposed KV cache

[Magnushst]

FloatsPerVector() returned hwy::VectorBytes() / sizeof(float), which is the vector width of the target that Highway's own library dispatches to. The flash attention kernels instead use hn::Lanes(df) of the target that Gemma dispatches to, and Gemma compiles a different set of targets (GEMMA_DISABLED_TARGETS). When the two widths differ, the transposed K/V cache is reshaped and written with one tile width but read with another.

For example, TestAttention in flash_attention_test aborts on the EMU128 target (Assert b != T2{0} in hwy::DivCeil): libhwy has no EMU128 code, so hwy::VectorBytes() returns 1 and the reshape factor is 0. On Arm CPUs with 256-bit SVE, such as Graviton 3, libhwy can dispatch to SVE_256 (8 floats), whereas Gemma disables SVE_256 and uses NEON_BF16 (4 floats). I have not been able to test on such hardware.

This takes the width from hn::Lanes in the per-target callers, passes it to MaybeReshapeCache, and removes FloatsPerVector(). The tile width is now also a compile-time constant on fixed-width targets, so TransposeKVCacheRow, which runs for every token, layer and KV head, no longer makes an indirect call through Highway's dispatch table.

Testing

• flash_attention_test, with each case in its own process, on AVX2 and EMU128: before, 19/20 pass and TestAttention/EMU128 aborts; after, 20/20 pass.
• The full CMake build (all targets) succeeds.