write_point_cloud segfaults unconditionally (SIGSEGV) on aarch64 Linux under Docker Desktop for Mac (Apple Silicon virtualization)

## Describe the bug

`o3d.io.write_point_cloud()` segfaults (SIGSEGV) on every call, unconditionally, when running the official `manylinux_2_31_aarch64` wheel inside a Docker container on Docker Desktop for Mac (Apple Silicon). This reproduces with pure synthetic data — no real files, no concurrency, no other load.

Writing crashes; reading/constructing geometry does not. Everything up to the write call runs fine.

## Environment

- **Open3D version**: 0.18.0 (pip)
- **OS**: Debian GNU/Linux 13 (trixie), inside a `python:3.11-slim` base image
- **Python**: 3.11.15
- **Container platform**: `linux/arm64` (native — no explicit emulation requested)
- **Host**: macOS 26.5.2, Apple Silicon (arm64)
- **Docker**: Docker Desktop, server version 29.6.1
- **Install method**: `pip install open3d` inside the container (resolves to the aarch64 wheel)

## To Reproduce

Minimal script, no external files or data needed:

```python
import open3d as o3d
import numpy as np

pcd = o3d.geometry.PointCloud()
pcd.points = o3d.utility.Vector3dVector(np.random.rand(10, 3).astype(np.float32))
o3d.io.write_point_cloud("/tmp/tiny.ply", pcd) # segfaults here
print("this line is never reached")
```

Run inside a container on Docker Desktop for Mac with default (native ARM64) platform:

```bash
docker run --rm python:3.11-slim bash -c "
pip install -q open3d numpy
python3 -c \"
import open3d as o3d, numpy as np
pcd = o3d.geometry.PointCloud()
pcd.points = o3d.utility.Vector3dVector(np.random.rand(10,3).astype(np.float32))
o3d.io.write_point_cloud('/tmp/tiny.ply', pcd)
print('OK')
\"
"
```

Result: process exits with code 139 (SIGSEGV), no Python traceback, no stderr output beyond an unrelated `onnxruntime`-style `cpuinfo` warning we see elsewhere in the same environment (not from open3d itself, but suggests CPU-feature-detection may be unreliable in this virtualized ARM64 environment generally).

## Expected behavior

`write_point_cloud` should either succeed or raise a Python exception — not crash the interpreter with an unhandled signal.

## What I've isolated so far

- Reproduces with both `write_ascii=True` and the binary default — format is not the differentiator.
- Reproduces with as few as 10 points and with real ~27k-point clouds from an actual pipeline.
- Reproduces with a single process, zero concurrency, writing to both a plain container filesystem path (`/tmp`) and a bind-mounted host volume — so it isn't specific to any particular filesystem/mount type.
- Does **not** reproduce under `--platform linux/amd64` (x86_64, run via Rosetta 2 emulation on the same Mac) — same script, same container base image, only the platform flag changed, and `pip install` then resolves a different (x86_64) wheel that works correctly. This strongly suggests the bug is specific to the aarch64 wheel's native code (possibly in the bundled TBB, given a CPU-vendor-detection warning we see elsewhere in the same environment from an unrelated library using the `cpuinfo` project — worth checking if Open3D's aarch64 build links a similar CPU-dispatch mechanism).

## Workaround

Forcing `platform: linux/amd64` (x86_64 emulation via Rosetta 2) in the container config avoids the bug entirely, at the cost of running the whole container under CPU emulation instead of natively.

Start with the minimal Python reproducer centered on o3d.io.write_point_cloud and compare the native linux/arm64 wheel with the working linux/amd64 case. Inspect the aarch64 wheel's native dependencies and CPU-dispatch behavior, including the bundled TBB hypothesis; done means ARM64 writes no longer segfault and either succeeds or raises a Python exception.

Written by the indexing model from the issue text.