ci: fix release.yaml so v0.3.1+ auto-publishes a complete release

Three changes that should have happened pre-v0.3.0:

1. Add a build-disk-arm64 job that runs on the arm64-linux runner (Odroid),
   building kernel + rootfs + disk-image then xz-compressing the .arm64.img.
   The previous release.yaml shipped x86_64 only.

2. Replace softprops/action-gh-release@v2 with a direct curl against Gitea's
   /api/v1/repos/<owner>/<repo>/releases endpoint. The softprops action
   hard-codes api.github.com instead of honouring ${{ github.api_url }},
   so on Gitea's act_runner it succeeds silently without creating a
   release. The curl path uses the auto-populated ${{ secrets.GITHUB_TOKEN }}
   for auth; doc note in ci-runners.md covers the GITEA_TOKEN fallback.

3. Downgrade actions/upload-artifact and actions/download-artifact from
   @v4 to @v3 to match Gitea act_runner v1.0.x's compatibility — same fix
   we applied to ci.yaml in 0c6e200.

Also compress the x86 disk image with xz before uploading (parity with
the arm64 path, saves ~95% on bandwidth), and emit SHA256SUMS over all
attached artifacts.

docs/ci-runners.md gains a "Workflows in this repo" table, a per-job
breakdown of the release pipeline, the rationale for direct-curl over
the marketplace action, and a "manually re-running a release" section
warning against force-updating published tags.

This commit fixes the workflow but does not retroactively rebuild v0.3.0.
v0.3.0's release page already has the manually-uploaded arm64 image and
SHA256SUMS; x86 users who want the v0.3.0 artifact build from source
(documented in the release body). v0.3.1 will be the first tag that
exercises the fixed workflow end-to-end.

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

docs/ci-runners.md

@@ -26,6 +26,63 @@ Generic ubuntu jobs that don't care about arch fall through to whichever runner
 them up first; on the Odroid they run in Docker via the `ubuntu-latest` /
 `ubuntu-22.04` / `ubuntu-24.04` labels.
 
+## Workflows in this repo
+
+| Workflow file | Trigger | Where it runs | What it produces |
+|---|---|---|---|
+| `.gitea/workflows/ci.yaml` | push / PR to main | ubuntu-latest | Go tests, cross-arch binary build, shellcheck |
+| `.gitea/workflows/build-arm64.yaml` | push to main, tags `v*`, manual | `arm64-linux` (Odroid) | ARM64 kernel + rootfs + disk image; uploads as workflow artifact only |
+| `.gitea/workflows/release.yaml` | tags `v*` | mix: ubuntu-latest + `arm64-linux` | Full release: x86 ISO + disk, ARM64 disk, Go binaries, SHA256SUMS — posted to Gitea Releases via API |
+
+### Release workflow specifics
+
+`release.yaml` is what fires when you `git push origin vX.Y.Z`. The pipeline:
+
+1. **test** — `go test` cloud-init + update modules (ubuntu-latest).
+2. **build-binaries** — cross-compiles `kubesolo-cloudinit` and
+   `kubesolo-update` for linux-amd64 + linux-arm64 with the version baked
+   in via `-X main.version=…`.
+3. **build-iso-amd64** — runs `make iso disk-image` on ubuntu-latest;
+   produces the x86_64 ISO and a `.img.xz` compressed disk image.
+4. **build-disk-arm64** — runs the same flow on the Odroid (`arm64-linux`
+   label); produces `.arm64.img.xz`.
+5. **release** — downloads everything, computes `SHA256SUMS`, calls
+   Gitea's `POST /api/v1/repos/<owner>/<repo>/releases` to create the
+   release, then `POST .../releases/<id>/assets?name=…` once per asset.
+
+Authentication uses Gitea's built-in `${{ secrets.GITHUB_TOKEN }}` — the
+runner auto-populates that secret with repo-write scope. If your runner
+is configured without that automatic token (e.g. an older `act_runner`),
+generate a personal access token with `repo:write` scope, add it as an
+org secret named `GITEA_TOKEN`, and swap the `TOKEN: ${{ secrets.GITHUB_TOKEN }}`
+line in `release.yaml` for `TOKEN: ${{ secrets.GITEA_TOKEN }}`.
+
+### Why not the GitHub Marketplace release actions?
+
+`release.yaml` used to call `softprops/action-gh-release@v2`. That action
+hard-codes calls to `api.github.com` instead of using `${{ github.api_url }}`
+(which Gitea sets to its own API). On Gitea's act_runner the action fails
+silently — the job reports green but no release is created. We replaced
+it with a direct `curl` so the behaviour is explicit and debuggable.
+
+Similarly, `actions/upload-artifact@v4` and `@download-artifact@v4` are not
+fully implemented by act_runner v1.0.x. Pin to `@v3` until upstream
+support catches up.
+
+### Manually re-running a release
+
+Releases are immutable once published, but you can:
+
+- **Delete and recreate the release** through the Gitea UI on the
+  `releases/tag/vX.Y.Z` page, then push the tag again (Gitea reuses the
+  existing tag), and re-trigger the workflow via the Actions UI.
+- **Trigger the build-arm64 workflow manually** for a one-off arm64
+  artifact: Gitea UI → Actions → ARM64 Build → Run workflow.
+
+Don't force-update a published tag — anyone who already fetched it (or
+downloaded an asset) sees a checksum mismatch. Prefer cutting a new patch
+release (vX.Y.Z+1) over rewriting a published one.
+
 ## Registering a new runner
 
 ### Prerequisites