fix(compute): handle pure-Go comparison output offsets

[fallintoplace]

Rationale for this change

The pure-Go primitive comparison path assumes that a partial output byte always has enough input values to fill it. It also calculates the batch count before consuming that prefix. Short inputs can panic, while longer inputs can process the wrong ranges when the output starts at a non-byte-aligned offset.

This path is used by noasm builds and when the SIMD implementations are unavailable.

What changes are included in this PR?

• Clamp the prefix to the available value count.
• Recalculate batches after consuming the prefix.
• Pass exactly one batch to the array-array operation.
• Cover offsets 0 through 7 and lengths 0 through 65 for every underlying primitive comparison operation and all three operand shapes.

Are these changes tested?

Yes. The compute subtree tests, focused race tests, 100 repeated regression runs, and linux/amd64 noasm compilation pass. The regression also verifies that bits outside the output range remain unchanged.

Are there any user-facing changes?

Pure-Go numeric and decimal comparisons no longer panic or produce incorrect output for non-byte-aligned result offsets. There is no API change.