Publish v0.2.11 and document the host disk limit

- Pruned the superseded v0.2.0 and v0.2.9 releases through the API (~565 MB of
  assets) after the host root filesystem hit 100%, which blocked release uploads
  (HTTP 500 "no space left on device") and even git push ("unpacker error").
- Published v0.2.11 locally with the fixed script: all five artifacts verified on
  the release (Linux/Windows/macOS ports, NSIS installer, AppImage).
- TODO records the remaining ~150 MB headroom and the exact host cleanup commands;
  MEMORY and RELEASING describe the disk failure mode and the pruning.

TODO.md

@@ -35,11 +35,11 @@ Verified via API+host credentials (2026-10-31):
       Gitea runner does not expose `github.token`).
 - [x] Uploads now fail loudly and the release is verified to carry every artifact
       (a silent HTTP 4xx used to leave an empty release with a green job).
-- [ ] **Host disk is full** (`/` 7.8G, 100%, 0 bytes free) so release uploads fail with
-      HTTP 500 `Attachments.Save: no space left on device`. Root-owned data is using the
-      space; `sudo journalctl --vacuum-size=100M` (~700 MB in `/var/log/journal`),
-      `sudo apt-get clean` (~90 MB), and clearing `attachments/tmp` would unblock it.
-      Alternative: prune superseded releases (v0.2.0 + v0.2.9 assets ≈ 565 MB).
+- [x] Unblocked by pruning the superseded v0.2.0 and v0.2.9 releases (~565 MB) and
+      publishing v0.2.11 locally; all five artifacts are on the release.
+- [ ] **Host disk is still tight** (`/` 7.8G, ~150 MB free). Before the next release, run
+      on 192.168.88.30 as root: `journalctl --vacuum-size=100M` (journal is 837 MB),
+      `apt-get clean` (91 MB), and clear `/var/lib/gitea/data/attachments/tmp`.
 - [ ] Verify the fallback on the next tag push produces a release automatically (the
       v0.2.11 tag build reached the publish step and created the release; only the
       upload failed on disk space).