GH-50054: [C++][IPC] Validate indices buffer size in ReadSparseCOOIndex

[metsw24-max]

Rationale for this change

ReadSparseCOOIndex builds the indices Tensor of shape {non_zero_length, ndim} over indicesBuffer with no size check, unlike the sibling ReadSparseCSXIndex. A crafted COO message with a large non_zero_length and a small buffer produces an index tensor that overruns its buffer, giving an out-of-bounds read when the sparse tensor is consumed (for example, converted to dense). A non_zero_length near INT64_MAX also overflows the non_zero_length * ndim * byte_width size product.

What changes are included in this PR?

A minimum-size guard on indicesBuffer in ReadSparseCOOIndex, mirroring the existing check in ReadSparseCSXIndex and using MultiplyWithOverflow for the size computation.

Are these changes tested?

The guard is a no-op for the valid inputs covered by the round-trip tests in cpp/src/arrow/ipc/tensor_test.cc; the rejection and overflow behaviour was checked against a standalone reproducer of the size computation.

Are there any user-facing changes?

Reading a malformed sparse COO tensor message now returns Status::Invalid instead of constructing an out-of-bounds index tensor.

This PR contains a "Critical Fix". A malformed IPC SparseTensor (COO) message could trigger an out-of-bounds read when the resulting sparse tensor is consumed.

• GitHub Issue: [C++][IPC] ReadSparseCOOIndex does not validate the size of the indices buffer #50054

[github-actions]

⚠️ GitHub issue #50054 has been automatically assigned in GitHub to PR creator.

[metsw24-max]

gentle ping

[pitrou]

@rok Can you take a look at this?

[rok]

This makes sense.

[conbench-apache-arrow]

After merging your PR, Conbench analyzed the 4 benchmarking runs that have been run so far on merge-commit a6c2018.

There were no benchmark performance regressions. 🎉

The full Conbench report has more details. It also includes information about 21 possible false positives for unstable benchmarks that are known to sometimes produce them.