build(deps): bump ort to 2.0.0-rc.13, centralise the CUDA provider

[jayhesselberth]

Supersedes #167.

rc.13 moved the execution provider: ort::execution_providers::CUDAExecutionProvider → ort::ep::CUDA, with the same .build() and the same with_execution_providers around it. A rename, not a behaviour change — but it broke two files at once, so the construction now lives in one place (escapepod-demux/src/ort_ep.rs) and the next RC rename is a one-line fix.

On the = pin

Worth stating explicitly, because it looks like the fragile part and is actually the opposite.

Keeping = 2.0.0-rc.13. Without the =, Cargo's pre-release matching lets ^2.0.0-rc.12 resolve to rc.13 on any lockfile refresh — so this break would have arrived unprompted rather than when someone chose to bump. The pin is what makes it a decision.

There is no stable 2.0 to move to. rc.13 is the newest published version of the crate; ort has been in RC throughout. So a semver range would not buy protection here, it would only remove the one guard we have.

The exposure is contained. ort is optional and reached only through the cnn-gpu / crf-gpu features, neither of which is in the default cli build. The CPU inference path is tract and is unaffected, so an ort break never reaches a default build or a released binary.

The residual cost is that every RC bump needs a look. Centralising the provider construction makes that look cheap; the alternative — an unpinned range on a pre-release crate — makes it arrive at random times instead.

Verification

--features cnn-gpu,crf-gpu: cargo check clean, cargo fmt --check clean, clippy adds no new warnings.

Note

cargo test --workspace --all-features has a pre-existing flake unrelated to this change: demux::models::cache_dir_precedence mutates process-global env vars while cargo runs tests in parallel, so it races. It passes serially and on unmodified main in isolation. Fixed separately so this bump stays revertable on its own.

🤖 Generated with Claude Code