[C++] Synthetic OOM tests are allocator-sensitive with mimalloc

### Describe the bug, including details regarding any error messages, version, and platform.

### Describe the bug

Two C++ unit-test paths use synthetic "impossibly large" allocations to assert `OutOfMemory`:

- `TypedTestBuffer.ResizeOOM` in `/Users/kaitlyndavis/dev/github.com/k8ika0s/arrow_s390x/cpp/src/arrow/buffer_test.cc`
- `TestMemoryPoolBase::TestOOM` (used by `arrow-misc-test`) in `/Users/kaitlyndavis/dev/github.com/k8ika0s/arrow_s390x/cpp/src/arrow/memory_pool_test.h`

On some allocator/platform combinations (notably with `mimalloc` enabled), the near-`max` request can trigger allocator fatal behavior before Arrow can surface `Status::OutOfMemory`. This makes the test behavior allocator-dependent and can cause instability in CI/dev runs.

### To Reproduce

Build C++ tests with mimalloc enabled and run OOM-focused cases, for example:

```bash
cmake -S cpp -B build -DARROW_BUILD_TESTS=ON -DARROW_MIMALLOC=ON -DARROW_JEMALLOC=OFF
cmake --build build --target arrow-buffer-test arrow-misc-test -j
./build/debug/arrow-buffer-test --gtest_filter='*ResizeOOM*'
./build/debug/arrow-misc-test --gtest_filter='*OOM*'
```

### Expected behavior

Synthetic OOM tests should be deterministic and should not depend on allocator internals/fatal paths.

### Actual behavior

With mimalloc, the "max-size" synthetic OOM request may not reliably produce Arrow OutOfMemory; behavior can depend on allocator failure mode.

### Proposed fix
- Keep synthetic OOM tests, but clamp requests to a still-impossible size (e.g. 1 << 48, 256 TB) instead of raw near-max bounds.
- Skip these synthetic OOM checks under mimalloc backend where allocator fatal path can bypass Arrow error propagation.

This is test-only hardening (no production runtime code changes).

### Component(s)

C++