Fix LoMa BF16 CUDA probing with CPU bookkeeping nodes - #4895

Inspect CUDA graph assignments so LoMa BF16 accepts supported CPU bookkeeping nodes while keeping numerical work on CUDA.

### Changes

- Allow selected CPU shape/index operators during CUDA capability probes; reject other CPU operators and require CUDA work.
- Keep strict probing on older ONNX Runtime and CoreML, and FP32 fallback on pre-Ampere GPUs.

### Tests

- **RTX 3060 / ORT 1.30:** 11 tests pass. Real LoMa B FP32/BF16 self-matches: **64/64 and 128/128**; default FP32 matches the base exactly.
- Reproduced the original strict BF16 probe failure.

### Compatibility

- **Windows 10 / GTX 1080 / ORT 1.30 CUDA 12:** 11 tests pass without skips. GPU FP32 and BF16-to-FP32 fallback match base and CPU exactly at 64/128 features.
- ORT 1.23.2 and 1.30 CPU SDKs: **9 tests each, 20 matching calls**, exact pairs.

### Build

- Changed CUDA-enabled source units compile against both SDKs.
- Full CLI links; `--help` exits 0.

Upstream review: colmap#4895.

Totally vibe coded

)

Fixes #4787. Supersedes #4895.

## Problem
With `--LomaMatching.use_bf16 1` on CUDA, the bf16 LoMa matcher always
fails to initialize and falls back to fp32:

```
Failed to initialize the bf16 LoMa matcher (This session contains graph nodes that are assigned to the default CPU EP, but fallback to CPU EP has been explicitly disabled by the user.); falling back to fp32
```

The bf16 models are loaded as capability probes, which set
`session.disable_cpu_ep_fallback`. But ONNX Runtime deliberately runs
small shape computations on the CPU, whatever the precision of the
model: its CUDA `Shape`/`Size` kernels write their output to host
memory, and `GetCpuPreferredNodes` then moves their int64 consumers
(`Gather`, `Unsqueeze`, `Concat`, `Cast`, `Reshape`, ...) to the CPU EP.
Tensors in bf16 or fp16 are never moved. The dynamic-shape matcher
graphs contain such nodes, so the probe always rejects them. The fp32
models are not loaded as probes, so they run with the same CPU nodes.

## Fix
Load the bf16 models like any other model, and decide up front whether
to use them:
- The bf16 models are only used with the CUDA execution provider, on
GPUs with compute capability 8.0 (Ampere) or newer. Otherwise, the fp32
models are loaded directly, without first downloading and loading the
bf16 models.
- On older GPUs, creating a bf16 session can succeed while inference
fails, which the fallback on initialization failures would not catch.
- On the CPU, `use_bf16` is now a no-op instead of trying to load the
bf16 models.
- The bf16 models are loaded as regular `ONNXModel`s, with a fallback to
fp32 if initialization throws an `Ort::Exception`. This removes
`ONNXModel`'s `is_capability_probe`, whose only user was LoMa.
- New `CudaDeviceSupportsBf16()` queries the device. It returns false if
the device cannot be queried, and on HIP builds.
- New `SelectONNXCudaDevice()` resolves `gpu_index` to the device that
`ONNXModel` runs on, shared with the bf16 check.
- Updated the option docs (C++, pycolmap, `doc/features.rst`).

This is the same pattern as the fp16 FlexGlue matcher in #4908: reduced
precision only on CUDA, a regular session, and a fallback to fp32 on
initialization failures.

### Comparison with #4895
#4895 keeps the strict probe and instead inspects the EP graph
assignment (ORT >= 1.24) against an allowlist of CPU operators. This PR
avoids:
- the allowlist, which is brittle: which nodes ORT moves to the CPU
depends on data flow, not on the operator type. For example, FlexGlue's
matchers run `Reshape` on the CPU, which the allowlist rejects. Any
rejected node silently falls back to fp32 again.
- the `ORT_API_VERSION >= 24` gating; the fix also works with older ORT.
- downloading and loading the bf16 models on GPUs without bf16 support
before rejecting them.
- ~80 lines of hand-encoded ONNX test models.

Removing the strict probe barely weakens the check: the bf16 tensors
themselves are never moved to the CPU, and the CPU EP has almost no bf16
compute kernels, so a bf16 op without a CUDA kernel still fails at
initialization and falls back to fp32.

## Tests
- `util/cuda_test`: `CudaDeviceSupportsBf16` returns false for invalid
devices and, with a GPU, leaves no CUDA error.
- `util/onnx_test`: `SelectONNXCudaDevice`, and an invalid model throws
the `Ort::Exception` that the LoMa fallback catches.
- `feature/loma_test`, `util/onnx_test`, `util/cuda_test` (also with
`CUDA_VISIBLE_DEVICES=""`) pass locally (CUDA + ONNX build).
- Not yet run end-to-end with the CUDA EP: ORT 1.30's CUDA EP does not
load on my machine (older system CUDA runtime). The bf16 LoMa-B matcher
with CPU shape nodes was validated in #4895 (64/64 and 128/128
self-matches on an RTX 3060).

**Stack:** the FlexGlue stack builds on this PR: #4907, #4921, #4908,
#4915. #4908 selects its fp16 matcher the same way, with a new
`CudaDeviceHasTensorCores()` (compute capability ≥ 7.0) next to
`CudaDeviceSupportsBf16()`. #4915 uses `SelectONNXCudaDevice()` for the
GPU feature cache.

Inspect CUDA graph assignments so LoMa BF16 accepts supported CPU bookkeeping nodes while keeping numerical work on CUDA.

### Changes

- Allow selected CPU shape/index operators during CUDA capability probes; reject other CPU operators and require CUDA work.
- Keep strict probing on older ONNX Runtime and CoreML, and FP32 fallback on pre-Ampere GPUs.

### Tests

- **RTX 3060 / ORT 1.30:** 11 tests pass. Real LoMa B FP32/BF16 self-matches: **64/64 and 128/128**; default FP32 matches the base exactly.
- Reproduced the original strict BF16 probe failure.

### Compatibility

- **Windows 10 / GTX 1080 / ORT 1.30 CUDA 12:** 11 tests pass without skips. GPU FP32 and BF16-to-FP32 fallback match base and CPU exactly at 64/128 features.
- ORT 1.23.2 and 1.30 CPU SDKs: **9 tests each, 20 matching calls**, exact pairs.

### Build

- Changed CUDA-enabled source units compile against both SDKs.
- Full CLI links; `--help` exits 0.

Upstream review: colmap#4895.

Totally vibe coded