Extract shared atomic-publish helper in shell command template

[OwenPriceSkelly]

What changed

After #138 and #139, shell_command.sh.jinja contained two near-identical copies of the build-in-temp-then-atomically-publish idiom: one for the uv bootstrap dir ($UV_BOOT_TMP → $UV_BOOT) and one for the cached environment ($ENV_TMP → $ENV_DIR). This extracts a single groundhog_publish TMP FINAL [VALIDATE_CMD...] helper, defined once near the top of the template, and calls it from both sites.

The two sites had diverged slightly in review, so the optional validation command does double duty to unify them while preserving each site's exact prior semantics:

• Bootstrap passes uv_works (runs $1/bin/uv --version): the fresh install is validated before publishing, an existing-but-broken $UV_BOOT (e.g. after a partial scratch purge) is treated as unusable and cleared before the rename, and a racer's working publish is kept over ours. uv_works also replaces the inline --version checks at the reuse and selection gates.
• Env passes no validation command: an existing $ENV_DIR counts as usable and is never cleared, exactly as before.

The helper (and uv_works) use subshell function bodies f() ( ... ) rather than { ... }, so they contain no literal braces — no {% raw %} blocks or brace-doubling needed for Globus Compute's .format() call on the rendered command.

Substring assertions in TestEnvReuseTemplating and TestUvBootstrapTemplating are updated to target the helper, including a check that it is defined once and called from exactly two sites.

Verification

• uv run pytest tests/ -q: 370 passed
• uv run ruff check . and uv run ty check .: clean
• Rendered a real script (with [tool.uv] config), applied .format(), and verified with bash -n
• Functionally exercised the extracted helper in bash across six scenarios: plain publish, lost race (discard), invalid build discarded, stale destination repaired, valid destination kept over ours, and no stray nested copy after an mv race

🤖 Generated with Claude Code