Sync benchmark env to PyTorch 2.13 to match fvdb-core build (#318)

## Problem

Nightly benchmarks have failed since 2026-08-20 ([run
32362276082](https://github.com/openvdb/fvdb-reality-capture/actions/runs/32362276082)).
Both benchmark jobs fail under the step named *"Download mipnerf360
dataset"*, but the download isn't what breaks — that step invokes
`frgs`, which imports fVDB:

```
ImportError: .../site-packages/fvdb/libfvdb.so: undefined symbol:
  _ZN3c1010ValueErrorC1ENS_14SourceLocationENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE
```

Demangled: `c10::ValueError::ValueError(c10::SourceLocation,
std::string)` — a libtorch symbol.

## Root cause

The nightly builds the fvdb-core wheel in one environment and installs
it into another, and the PyTorch pins had drifted apart:

| Env | File | PyTorch |
|---|---|---|
| Wheel build | `fvdb-core/env/build_environment.yml` | 2.13.0 |
| Benchmark run |
`tests/benchmarks/comparative/docker/benchmark_environment.yml` | 2.11.0
|

fvdb-core landed [PyTorch 2.13
(openvdb/fvdb-core#738)](openvdb/fvdb-core#738)
on 2026-08-20, bumping its build env from 2.11.0 to 2.13.0. This env was
not updated, so `fvdb_core-0.6.0.dev0-cp312-cp312-linux_x86_64.whl` was
compiled against libtorch 2.13 and then loaded against libtorch 2.11.
The Aug 19 nightly passed; Aug 20 was the first failure.

## Fix

Bump `pytorch-gpu` to 2.13.0 to match fvdb-core.

Verified by solving the full environment (linux-64,
`CONDA_OVERRIDE_CUDA=13.0`) with only this line changed:

```
pytorch      2.13.0   cuda130_mkl_py312_hcdc9d04_302
libtorch     2.13.0   cuda130_mkl_h1ca3d63_302
torchvision  0.28.0   cuda130_py312_haac1422_1
pycolmap     3.13.0   cpu_py312hac8e9dd_1
cuda-version 13.0
```

`torchvision` follows to 0.28.0 automatically, `cuda-version=13.0` is
unchanged, and the existing `pycolmap<4` bound still resolves to 3.13.0
— so this change is isolated to the PyTorch stack.

## Recurrence

This is the third time these two files have drifted: 1b6956f (2.8→2.10),
6c2ede6 (2.10→2.11), and now 2.11→2.13. I've added a comment on the pin
recording that the two must move together, but a comment is not a guard
— worth considering a CI check that compares the two pins, or having the
fvdb-core torch bump update both. Happy to file a follow-up issue if
useful.

## Testing

The real verification is a nightly benchmark run, which this PR's checks
don't exercise. Recommend a manual workflow dispatch after merge rather
than waiting for the schedule.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Signed-off-by: Mark Harris <mharris@nvidia.com>
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: harrism

tests/benchmarks/comparative/docker/benchmark_environment.yml

@@ -51,7 +51,10 @@ dependencies:
   - pycolmap>=3.11,<4
   - pytest-benchmark
   - python=3.12
-  - pytorch-gpu=2.11.0
+  # Keep in sync with fvdb-core's env/build_environment.yml: the nightly builds the
+  # fvdb-core wheel in that env and installs it here, so a mismatch is an ABI break
+  # (undefined libtorch symbols at `import fvdb`), not a version warning.
+  - pytorch-gpu=2.13.0
   - rich
   - scikit-build-core
   - scikit-learn