Retry the checkout sync in the app build

A push fires the web deploy and the app build at the same instant, and on commit
b03fb25 the second SSH session to Gitea came back with "Failed to update public
key" 32 seconds in. The pull succeeded by hand immediately afterwards, so it was
contention between the two runs rather than anything about the code — but the job
had already failed and emailed "App build FAILED".

The pull is now attempted three times with a pause between, and only gives up
after the third. It is the one step here that depends on another machine being
responsive at a moment we do not control, so it is the one worth retrying.

The point is not the build: a false failure alert is what teaches you to ignore
the alert, and an ignored alert is how the off-site backup sat dead for eight days
without anyone noticing.

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

.gitea/workflows/build-apps.yml

@@ -45,7 +45,18 @@ jobs:
           cd "$APP"
 
           echo "── syncing the checkout ──"
-          git pull --ff-only
+          # Retried, because this is the one step that talks to another machine. A push
+          # fires the web deploy and this build at the same moment, and Gitea has been seen
+          # to answer the second SSH session with "Failed to update public key" — a
+          # transient contention error that has nothing to do with the code. Without a
+          # retry that blip emails "App build FAILED", which is precisely the false alarm
+          # that makes an alert worth ignoring.
+          for attempt in 1 2 3; do
+            if git pull --ff-only; then break; fi
+            if [ "$attempt" = 3 ]; then echo "git pull failed three times — giving up"; exit 1; fi
+            echo "   pull failed (attempt $attempt), retrying in 15s"
+            sleep 15
+          done
 
           echo "── dependencies ──"
           ( cd mobile && npm install --no-audit --no-fund >/dev/null )