chore: rename scripts/test-branch-on-hetzner to test-on-hetzner

It's not just for testing a branch anymore -- deploy --image/--branch,
start --containerized, validate, and the bucket lifecycle all work
identically whether the container was built from a dev branch or
pulled as an already-built release image (verified end-to-end: the
#749 investigation ran the fix straight from main, and the very next
smoke test used a real v0.8.0 release image, through the exact same
containerized path). 'test-branch-on-hetzner' undersold that for a
while.

Pure rename plus reference updates (README.md/cloud_test.py's own
opening lines included, since those undersold it too) -- no logic
changes. git mv preserved history; CI workflow triggers didn't need
touching (scripts/**, **/*.sh globs, not hardcoded to the old path).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Author: brawer

.github/workflows/shellcheck.yml

@@ -3,8 +3,7 @@
 
 name: ShellCheck
 
-# Lints every shell script in the repo (scripts/, including
-# scripts/test-branch-on-hetzner/remote/) with shellcheck -- a hard gate,
+# Lints every shell script in the repo with shellcheck -- a hard gate,
 # same style as cargo-deny.yml: the job fails outright on any finding,
 # not just an informational annotation.
 

.github/workflows/test-scripts.yml

@@ -4,7 +4,7 @@
 name: Test scripts
 
 # Runs pytest over scripts/ -- currently just
-# scripts/test-branch-on-hetzner/tests/, see #737. Path-filtered and not
+# scripts/test-on-hetzner/tests/, see #737. Path-filtered and not
 # added to the branch protection required-checks list, same reasoning as
 # shellcheck.yml: a plain context-name-matched required check expects a
 # status on every PR, which a path-filtered workflow can't guarantee for

docs/TESTING.md

@@ -13,8 +13,12 @@ two copies going stale independently.
 - **Integration tests**: [`tests/`](../tests) — a full pipeline run
   against a real OSM extract (a Swiss shopping mall) plus minimal
   AllThePlaces data. Fast enough to run on every `cargo test`.
-- **Script tests**: [`scripts/test-branch-on-hetzner/tests/`](../scripts/test-branch-on-hetzner/tests) —
-  run `uv run pytest` from `scripts/`.
+- **Script tests**: [`scripts/test-on-hetzner/tests/`](../scripts/test-on-hetzner/tests) —
+  run `uv run pytest` from `scripts/`. Writing tests for a script whose
+  own job is testing things sounds like a step too far at first, but
+  it’s paid for itself every time that script itself needed a change:
+  the alternative feedback loop is a real Hetzner VM, minutes per
+  iteration and real money, versus a sub-second local test run.
 
 ## CI
 
@@ -29,7 +33,7 @@ pushes touching `scripts/**/*.sh` run
 `scripts/**` run
 [`test-scripts.yml`](../.github/workflows/test-scripts.yml) (`pytest`
 for the scripts that have real test coverage — currently just
-`scripts/test-branch-on-hetzner/`). PRs and pushes that touch
+`scripts/test-on-hetzner/`). PRs and pushes that touch
 `Cargo.toml`, `Cargo.lock`, or `deny.toml` run
 [`cargo-deny.yml`](../.github/workflows/cargo-deny.yml) — dependency
 licenses, banned/duplicated crates, sources, and known RUSTSEC/OSV
@@ -75,7 +79,7 @@ real hardware before a change lands, not automated gates:
 
 - [`scripts/test-branch-on-macos/`](../scripts/test-branch-on-macos) —
   full pipeline on your dev machine. Free, fast to iterate with.
-- [`scripts/test-branch-on-hetzner/`](../scripts/test-branch-on-hetzner)
+- [`scripts/test-on-hetzner/`](../scripts/test-on-hetzner)
   — full pipeline on real cloud hardware, either built from your
   feature branch or pulled as an already-built image (e.g. a released
   container), optionally run containerized under a real cgroup

scripts/README.md

@@ -42,7 +42,7 @@ process these fit into.
 Unrelated to how `osm-diffs` actually ships to production — this is for
 ad hoc validation of a branch before it lands.
 
-- [`test-branch-on-hetzner/`](test-branch-on-hetzner/README.md): spins
+- [`test-on-hetzner/`](test-on-hetzner/README.md): spins
   up a Hetzner Cloud VM, builds a given git branch on it, runs the
   pipeline against it, and pulls back logs — one command instead of
   repeating the manual setup by hand each time. See

scripts/test-branch-on-macos/README.md

@@ -4,14 +4,14 @@ Build the current checkout, run the pipeline against a workdir, and
 monitor `vm_stat`/RSS alongside it -- so testing a change doesn't mean
 re-typing the same monitoring loop by hand each time.
 
-Much smaller than [`../test-branch-on-hetzner/`](../test-branch-on-hetzner)
+Much smaller than [`../test-on-hetzner/`](../test-on-hetzner)
 on purpose: no VM lifecycle to manage, no branch to clone -- everything
 runs on the machine you're already on, against whatever's currently
 checked out. It also doesn't build via the project's `Containerfile`
 the way that tool does: plain `cargo build --release` here, not
 matching production's exact toolchain, because the point is fast
 turnaround on a local edit-run loop, not comparable-to-production
-numbers. Use `test-branch-on-hetzner` when the toolchain match or real
+numbers. Use `test-on-hetzner` when the toolchain match or real
 hardware actually matters.
 
 ## Usage
@@ -50,6 +50,6 @@ during the run -- every subsequent `ps -p` call just failed with
 useless log. `monitor.sh` re-resolves it via `pgrep` on every 5-second
 tick instead.
 
-`scripts/test-branch-on-hetzner/analyze.py` can be pointed at
+`scripts/test-on-hetzner/analyze.py` can be pointed at
 `pipeline.log` from a local run here too -- the log format is identical
 either way.

scripts/test-branch-on-macos/test_macos.py

@@ -3,7 +3,7 @@
 against a workdir, and monitor vm_stat/RSS alongside it -- so testing a
 change doesn't mean re-typing the same vm_stat loop by hand each time.
 
-See scripts/test-branch-on-hetzner/ for the equivalent against real
+See scripts/test-on-hetzner/ for the equivalent against real
 cloud hardware; this is deliberately much smaller -- no VM lifecycle to
 manage, no branch to clone, since the whole point is fast iteration on
 whatever's currently checked out on this machine. It also doesn't build

scripts/test-branch-on-hetzner/.gitignore scripts/test-on-hetzner/.gitignorescripts/test-branch-on-hetzner/.gitignore renamed to scripts/test-on-hetzner/.gitignore

@@ -1,4 +1,4 @@
-# Testing a branch on cloud machines
+# Testing on cloud machines
 
 Two small tools: `cloud_test.py` runs the full `osm-diffs` pipeline on
 real Hetzner Cloud hardware, without repeating the manual VM setup by

scripts/test-branch-on-hetzner/README.md scripts/test-on-hetzner/README.mdscripts/test-branch-on-hetzner/README.md renamed to scripts/test-on-hetzner/README.md

@@ -1,9 +1,10 @@
 #!/usr/bin/env python3
-"""Spins up a Hetzner Cloud VM, builds osm-diffs from a given git branch,
-and runs the full pipeline against it -- so testing a development branch
-on real cloud hardware doesn't mean re-deriving the VM setup dance by
-hand each time. See README.md in this directory for the full story,
-including prerequisites and a worked example.
+"""Spins up a Hetzner Cloud VM and runs the full osm-diffs pipeline on it
+-- either built from a given git branch or pulled as an already-built
+image (e.g. a released `ghcr.io` container) -- so testing on real cloud
+hardware doesn't mean re-deriving the VM setup dance by hand each time.
+See README.md in this directory for the full story, including
+prerequisites and a worked example.
 
 Every `hcloud`/`ssh`/`scp` command this runs is echoed to stderr first,
 so a flag mismatch against your installed `hcloud` version should be