deps: lock the runtime dependencies with hashes

[z33b0t]

The second half of #10, taking your call on the fork:

yes, exclude torch (and its CUDA deps) from the compile

187 packages pinned exactly with hashes; Dockerfile installs with --require-hashes.

What's excluded, and what deliberately isn't

Excluded (all installed by the cu130 step that runs first): torch, triton, and the sixteen nvidia-* runtime packages.

Not excluded: torchaudio and torchmetrics. Worth flagging since they look like they belong with torch — they don't. I checked the running container: the cu130 install doesn't provide them, they come from PyPI as ordinary NeMo dependencies, so leaving them out would mean an unpinned hole in the middle of the tree.

The torch pin earns its keep

requirements.in pins torch==2.12.1 even though torch never reaches the output. That isn't decoration — without it the resolver drifts to PyPI's newest torch (2.13.0) and pins everything else against a torch the image never installs.

With the pin, the resolution reproduces the running container exactly:

	lock	live container
torchaudio	2.11.0	2.11.0
torchmetrics	1.9.0	1.9.0
numpy	2.4.6	2.4.6
nemo-toolkit	2.7.3	2.7.3

The Dockerfile's torch==2.12.1 and the requirements.in pin must stay in lockstep; both carry a comment saying so, and Dependabot is configured to ignore torch so it can't move one without the other.

Verified by building and running it, not by reading it

On the GPU box, separate tag/port/volume so the live daemon was untouched:

• Build succeeds under --require-hashes
• torch survives as 2.12.1+cu130, cuda available: True, bf16 supported: True — this was the real risk, since the install upgrades cuda-bindings/cuda-pathfinder that the cu130 step had brought in
• Transcription works: both audio/clean.wav and audio/noisy.wav come back correct
• The hash check actually bites — forged hashes are refused (Expected sha256 1111… Got 0f17b89f…), genuine ones install

Also here

• scripts/lock-requirements.sh holds the exclusion list, so it isn't a comment someone has to retype. It fails loudly if a cu130-provided package ever leaks into the lock.
• Dependabot gains the pip ecosystem. Read its first PR rather than merging on green: both lockfiles are uv-generated, and Dependabot's pip-compile support keys off the pip-tools header, so it may edit requirements.txt directly instead of regenerating it. If it does, close the PR and re-run the script.

Not included

requirements.in isn't added to server.yml's path filters — that file is under .github/workflows/, which I can't merge without the workflow scope. It belongs in #40, which already edits those filters.

Closes#10