Ship one binary with NPU + ROCm + CUDA support, fix CLI flag precedence

Adds breadmill's `full` feature (npu + rocm + cuda together) and switches
the release workflow to build with it. All three backends are ort's
load-dynamic (dlopen) mode, so combining them doesn't require the NPU/ROCm/
CUDA toolkits on the build host -- which backend is actually available is
resolved at runtime via ORT_DYLIB_PATH / the dynamic linker, per whichever
backend is selected for that run.

Also fixes a real bug this surfaced: backend selection checked
`config.model.backend == "rocm"` unconditionally in an if/else-if chain, so
an explicit --cuda (or --npu) flag silently lost to an unrelated `backend`
value already sitting in config.toml. CLI flags now always take priority
over config.

Version bump: breadmill 0.2.0 -> 0.2.1.

breadmill/Cargo.toml

@@ -1,6 +1,6 @@
 [package]
 name = "breadmill"
-version = "0.2.0"
+version = "0.2.1"
 edition = "2021"
 license = "MIT"
 
@@ -14,6 +14,13 @@ npu = ["ort/vitis", "ort/load-dynamic"]
 # libonnxruntime_providers_rocm.so, which most distros don't package.
 rocm = ["ort/migraphx", "ort/load-dynamic"]
 cuda = ["ort/cuda", "ort/load-dynamic"]
+# All backends in one binary. Safe to combine: every backend here uses
+# ort's load-dynamic (dlopen) mode, so none of this links against an actual
+# NPU/ROCm/CUDA toolkit at build time — which ONNX Runtime actually gets
+# loaded (and thus which EPs are really available) is decided at runtime by
+# ORT_DYLIB_PATH / the dynamic linker, per the --npu/--rocm/--cuda flag or
+# `backend` config value in use for that run.
+full = ["npu", "rocm", "cuda"]
 
 [[bin]]
 name = "breadmill"