fix(array): compare sparse union slices at relative offsets

[fallintoplace]

Rationale for this change

SparseUnion.setData already slices each child using the parent union offset. ApproxEqual adds that offset again, so sliced unions can compare the wrong child values or hit invalid slice bounds.

What changes are included in this PR?

Compare each selected child at its relative i:i+1 position, matching exact equality and the representation used by sparse unions.

Are these changes tested?

• go test ./arrow/array -run TestSparseUnionApproxEqualSlicesWithDifferentOffsets -count=1

Are there any user-facing changes?

No API changes. This corrects the reported behavior while preserving the existing ownership and compatibility contracts.

[zeroshade]

LGTM. The root cause is confirmed: union.setData already slices each sparse-union child by the parent offset (union.go L137-143), and RawTypeCodes() returns typecodes[offset:], so children and type codes are both already offset-adjusted. Adding data.offset again in arraySparseUnionApproxEqual double-counted the offset. The fix brings the approx-equal path in line with the already-correct exact-equality path (arraySparseUnionEqual, L454), and dense unions are correctly left untouched.

Verified locally:

• New test passes; full ./arrow/array -run Union suite passes.
• Regression proof: reverting only the union.go change (keeping the test) makes the test fail, confirming it genuinely catches the bug.
• The test uses distinct offsets on each side over different underlying values, so it faithfully reproduces the reported issue.