docs: the v0.11.2 mystery was an unstamped-tag problem, not lost code

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

docs/build-status.md

@@ -1367,3 +1367,14 @@ Consequences until resolved:
 - The unpushed v0.10–v0.11 work needs to be found and pushed from whichever machine built it,
   or the deployed binary's provenance re-established some other way, before the release channel
   can be trusted again.
+
+**Resolved same day.** The binary itself settled it: `go version -m` on the deployed executable
+shows `vcs.revision=d5b1bab` — a commit on this repo's master — built 2026-08-02 08:36 UTC with a
+hand-stamped `-X main.Version=v0.11.2` and a dirty tree (`vcs.modified=true`, the then-uncommitted
+schema doc). An earlier session stamped release numbers ahead of the tag line; no code was ever
+missing. Current master is tagged and released as **server-v0.11.3** (signed), restoring a
+monotonic, tag-backed lineage above the deployed number. The rule going forward: **the version a
+binary is stamped with must be a pushed `server-v*` tag** — an ad-hoc stamp above the tag line
+poisons `/releases/latest` for the string-comparing updater the moment anyone tags honestly again.
+The stale `server-v0.9.2` release (same code lineage, wrong number, created during the confusion)
+remains in Gitea but is harmless now that v0.11.3 outranks it as latest.