build-status: server-v0.1.0 shipped with assets; only the image job remains

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

docs/build-status.md

@@ -154,13 +154,14 @@ Archived as `…-build2.json` in `echolot-prober/reports/`. The findings:
 
 ## Pipeline shakeout — 2026-07-30, partially done
 Repo pushed to git.rambossek.at/EchoLot/echolot (ssh :2222). Actions runner works:
-`server-test` green on push. `server-v0.1.0` tag → release **created but empty** — asset upload
-failed (likely Gitea's default `[attachment] ALLOWED_TYPES` rejecting extension-less binaries;
-job logs need a token/UI to confirm). Image job fails separately (runner probably lacks docker).
-To finish: (1) check the failed `server-release` job log in the Gitea UI; if it's the attachment
-type limit, either set `[attachment] ALLOWED_TYPES = */*` in app.ini or switch the workflow to
-.tar.gz assets (then teach server/internal/selfupdate to unpack); (2) decide whether the runner
-gets docker (image job) or images wait. Delete + re-push the tag to re-run.
+`server-test` green on push. `server-v0.1.0` release shipped with all assets
+(`echolot-server_linux_{amd64,arm64}` + `SHA256SUMS`) after two workflow fixes: mixed
+paths+tags triggers never fire (split into test-server.yml / build-server.yml), and a greedy
+`sed` grabbed a nested user id instead of the release id → uploads 404ed (first-match grep now;
+release creation also falls back to GET-by-tag on re-runs). Binaries verified downloadable →
+`--self-update` has its artifact source. **Still open: the `image` job** — needs a
+docker-capable runner (GITHUB_SERVER_URL inside the runner is the internal `http://app:3000`;
+set `ECHOLOT_REGISTRY_HOST=git.rambossek.at` as a repo variable/env when enabling it).
 
 ## Next steps
 1. Build locally, run on several physical devices (varied Android versions/vendors), collect the