Build the image on the branch that exists

The release workflow watched `master`. The repository's branch is `main`, so
the job that builds and pushes the image would have sat there never firing,
and the first sign of it would have been a deploy that never arrived.

The check workflow runs on every push and so was never affected, which is
exactly why this needed finding on purpose rather than by noticing.

.gitea/workflows/release.yml

@@ -10,7 +10,7 @@ name: Image
 on:
   push:
     branches:
-      - master
+      - main
 
 jobs:
   image:

README.md

@@ -109,7 +109,7 @@ cargo run -p runway-cli -- list-events --from 2026-08-24 --to 2026-08-31
 
 One image holds both halves — the server binary and the built frontend — so
 they cannot be deployed out of step with each other. CI builds and pushes it on
-every merge to `master`; a timer on the server picks it up. Nothing goes up
+every merge to `main`; a timer on the server picks it up. Nothing goes up
 from a laptop.
 
 ```sh

deploy/README.md

@@ -1,7 +1,7 @@
 # Deploying Runway
 
 The app is one image holding both halves — the server binary and the built
-frontend — pushed by CI on every merge to `master` and picked up by a timer on
+frontend — pushed by CI on every merge to `main` and picked up by a timer on
 the server. Nothing is copied from a laptop, and there is no step that can
 deploy one half without the other. That was the audit's one "do it differently"
 (F76): v1's frontend went up by `rsync` over SSH, by hand, separately from its
@@ -12,7 +12,7 @@ backend's CI.
 | | |
 |---|---|
 | Image | `git.rcjohnstone.com/connor/runway:latest`, and `:<commit>` |
-| Built by | `.gitea/workflows/release.yml`, on push to `master` |
+| Built by | `.gitea/workflows/release.yml`, on push to `main` |
 | Deployed by | `deploy/runway-update`, from a systemd timer |
 | Backend | `runway-backend` in `~/compose.yml`, on the `internal` network |
 | Frontend | `~/data/runway/dist`, served by the root Caddy from `/srv/runway` |