feat: isolate compute-node venv from login-node .venv/

Compute-node SLURM jobs now use `.venv-compute/` via UV_PROJECT_ENVIRONMENT
so `uv run` doesn't pick up the login node's `.venv/` (which may have
wrong-arch native modules on cross-arch clusters like Lyris/Ptyche).

Users install srtctl on the login node however they prefer (pip, uv sync,
uv pip install -e .). The compute node manages its own venv independently.

Tested on Lyris — mocker smoke test passes with .venv-compute/ created
on aarch64 compute while .venv/ exists for x86_64 login.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Author: alec-flowers

.gitignore

@@ -20,6 +20,7 @@ venv/
 env/
 ENV/
 .venv/
+.venv-compute/
 
 # uv
 .uv/

src/srtctl/templates/job_script_minimal.j2

@@ -82,6 +82,10 @@ echo "Preparing srtctl environment..."
 # This avoids arch mismatch when login node (x86_64) != compute node (aarch64)
 export PATH="${SRTCTL_SOURCE}/bin:$HOME/.local/bin:$PATH"
 
+# Use a compute-specific venv so we don't pick up the login node's .venv/
+# (which may be built for a different arch, e.g. x86_64 login vs aarch64 compute)
+export UV_PROJECT_ENVIRONMENT="${SRTCTL_SOURCE}/.venv-compute"
+
 if ! command -v uv &> /dev/null; then
     echo "ERROR: uv not found. Run 'make setup ARCH=<compute_arch>' first."
     echo "  e.g., make setup ARCH=aarch64  (for GB200/Grace compute nodes)"