JVM Panama vector kernels: accept slab-backed (offset) FP32 operands #1173

Follow-up of #1146 (noted in PR #1168). DefaultCpuOpsJvm's Panama vector paths guard on data as? FloatArrayTensorData ?: return null, so a slab-backed operand (StorageFloatTensorData, nonzero arrayOffset — what a ForwardScope produces since #1145/#1146) silently falls back to the common scalar-window loops. Correct, but the JVM loses SIMD exactly where the scope machinery is in use.

Scope

• Extend the JVM vector entry points (vectorFloatBinary, the unary/activation paths, the vector reduce, the vector FP32 matmul) to accept dense-FP32 windows — array + base offset — matching both FloatArrayTensorData (offset 0) and StorageFloatTensorData.
• Thread the offsets into JvmVectorKernels (FloatVector.fromArray(species, arr, base + i) supports them natively; add offset parameters defaulting to 0).
• Outputs already route through floatResult/adoptFloatArray (Route eager op outputs through ctx.memoryScope (DefaultCpuOps + decode-loop adoption) #1146) — unchanged.

Acceptance

• A jvmTest drives the vector-eligible shapes (exact-match binary, scalar and bias broadcasts, silu/relu, reduce-all, 2D matmul) with slab-backed operands at nonzero offsets and asserts bit-identical results vs Ambient.
• No behavioural change for offset-0 operands; benchmarks (ElementwiseAdd1MBench, MatmulBench) unaffected.