ci(deploy): switch to build + fly machine update for reliable in-place deploys

`fly deploy` for our single-machine + single-volume topology is
non-deterministic — sometimes it updates the existing machine in
place, sometimes it tries to provision a NEW machine alongside and
fails because the volume only has one attachment slot.  Hit this on
consecutive runs today with both strategy=rolling AND
strategy=immediate; the manual `fly machine update` recovery
worked reliably.

Workflow now does:
  1. flyctl deploy --build-only --push  (build + push image, no machine touch)
  2. capture the image tag from the build output
  3. flyctl machine update <id> --image <tag>  (explicit in-place API)

`fly machine update` targets a specific machine ID and cannot try
to create a parallel machine.  ~30-60s of downtime per deploy, same
as strategy=immediate on its best day, but reliably works.

Loops will be needed if we ever scale to multiple machines (or
migrate off SQLite-on-volume, which is the long-term unblocker for
zero-downtime deploys).

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

Author: Sbussiso

.github/workflows/deploy.yml

@@ -38,15 +38,64 @@ jobs:
 
       - uses: superfly/flyctl-actions/setup-flyctl@master
 
-      # `--depot=false` falls back to Fly's built-in remote builder
-      # (a Fly Machine running `docker build`).  Slower than depot
-      # (~3 min vs ~30s for a cached build) but doesn't depend on
-      # depot.dev's availability — depot has timed out twice in a
-      # row on consecutive deploys (2026-04-28), wedging CI for ~10
-      # min each before falling through to a final auth-handshake
-      # error.  Switch back to `--depot=true` (or remove the flag)
-      # once depot stabilises, or accept the slower-but-reliable
-      # path indefinitely if uptime matters more than build speed.
-      - run: flyctl deploy --remote-only --depot=false
+      # Why two-step (build → machine update) instead of plain `fly deploy`:
+      #
+      # We run a single Fly Machine with a single persistent volume
+      # (`opensentry_data` at /data, holding the SQLite DB).  `fly deploy`
+      # for this topology is non-deterministic: sometimes it sees the
+      # existing machine and updates it in place, sometimes it decides
+      # the image config has "drifted enough" and tries to provision a
+      # NEW machine alongside the old.  The new-machine path errors
+      # immediately because the volume only has one attachment slot:
+      #     "creating a new machine in group 'app' requires an
+      #      unattached 'opensentry_data' volume."
+      # We hit this on consecutive runs 2026-04-28 with strategy=rolling
+      # AND strategy=immediate, and `max_unavailable` is rolling-only so
+      # it didn't help either.
+      #
+      # `fly machine update --image …` is the explicit in-place API.
+      # It targets a specific machine ID, restarts it on the new image,
+      # and the volume stays attached throughout.  It cannot try to
+      # create a new machine.  ~30-60s of downtime per deploy (same as
+      # `strategy = "immediate"` on a good day) but reliably works.
+      #
+      # Note: `--depot=false` is intentional — depot.dev timed out
+      # twice in a row on 2026-04-28 (5 min each), wedging CI for
+      # ~10 min before failing.  Standard remote builder is slower
+      # (~3 min cached vs ~30s depot) but reliable.
+      - name: Build + push image to Fly registry
+        id: build
+        run: |
+          set -e
+          # --build-only --push: build the image and push to Fly's
+          # registry, but do NOT touch any machines.  The image tag is
+          # printed on a line like:
+          #   image: registry.fly.io/opensentry-command:deployment-XXXX
+          # Capture it so the next step can target it explicitly.
+          OUT=$(flyctl deploy --remote-only --depot=false --build-only --push 2>&1 | tee /dev/stderr)
+          IMAGE=$(echo "$OUT" | grep -oP 'image:\s+\K[^\s]+' | tail -1)
+          if [ -z "$IMAGE" ]; then
+            echo "::error::Could not find image tag in flyctl output"
+            exit 1
+          fi
+          echo "Captured image: $IMAGE"
+          echo "image=$IMAGE" >> "$GITHUB_OUTPUT"
         env:
           FLY_API_TOKEN: ${{ secrets.FLY_API_TOKEN }}
+
+      - name: Update machine in place
+        run: |
+          set -e
+          # We currently run exactly one machine.  If we ever scale to
+          # multiple machines (or migrate to LiteFS / Postgres so we
+          # don't need a single volume), this script needs to loop.
+          MACHINE=$(flyctl machines list -a opensentry-command --json | jq -r '.[0].id')
+          if [ -z "$MACHINE" ] || [ "$MACHINE" = "null" ]; then
+            echo "::error::No machines found for opensentry-command"
+            exit 1
+          fi
+          echo "Updating machine $MACHINE to $IMAGE"
+          flyctl machine update "$MACHINE" --image "$IMAGE" --yes -a opensentry-command
+        env:
+          FLY_API_TOKEN: ${{ secrets.FLY_API_TOKEN }}
+          IMAGE: ${{ steps.build.outputs.image }}