An update script that stopped where nobody could see it

Found by running it rather than by reading it. Under `set -euo pipefail` the tag
resolution added in the last commit dies when no release tag exists -- grep exits
1 when nothing matches, and `head -1` closing the pipe early can hand it a
SIGPIPE besides. That is every host until the first release is tagged, which is
every host today. It printed "== fetching ==" and stopped: fetched, not reset,
not restarted, and exit status swallowed by the pipe it was being read through.
The fallback comment two lines above claimed to handle exactly this case.

And the consequence of moving to SSH: install.sh takes REPO_URL from the running
checkout's origin, so whoever pushes over SSH now hands the deployment a URL the
service user cannot use -- it has no key and should not have one, being a
credential that can push to the repository sitting on a box to do a read-only
job. The clone would have failed loudly, with "Permission denied (publickey)"
from an account nobody was thinking about. It is refused up front with the fix
named instead.

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

deploy/update.sh

@@ -41,8 +41,13 @@ git_as fetch --quiet --tags --force origin "$BRANCH"
 # onto a release candidate on the strength of a hyphen.
 target="origin/$BRANCH"
 if [[ "$CHANNEL" == "stable" ]]; then
+  # `|| true` is load-bearing under `set -euo pipefail`, and for two reasons:
+  # grep exits 1 when nothing matches -- which is every host until the first
+  # release is tagged -- and `head -1` closing the pipe early can hand grep a
+  # SIGPIPE. Either kills the script mid-update, after the fetch and before the
+  # reset, leaving the checkout fetched and unmoved with no error printed.
   newest=$(git_as tag --list --sort=-v:refname \
-             | grep -E '^v?[0-9]+\.[0-9]+\.[0-9]+$' | head -1)
+             | grep -E '^v?[0-9]+\.[0-9]+\.[0-9]+$' | head -1 || true)
   if [[ -n "$newest" ]]; then
     target="$newest"
   else