docs: say the 2.x image is not published; show the local build (audit M6)

README, guide and deploy/docker-compose.yml pinned
ghcr.io/mixeme/selfpost:2.4.1, which does not exist: ghcr.io holds 1.0.0
and 1.3.0 only. The owner decided (2026-10-12) that old tags and images
stay untouched and the pin points forward, made true by the next
publication. Until then:

- README Quick start and guide Fixed image tag say the 2.x line is not on
  ghcr.io and show `docker build ... --build-arg VERSION=2.4.1 -t
  ghcr.io/mixeme/selfpost:2.4.1 .`; with the image present locally,
  docker run and Compose (pull_policy missing) use it without pulling.
- compose header says the same in two lines.
- development.md release steps: bump the version in those notes at each
  cut, remove them at the first publication of the line.
- CHANGELOG [Unreleased], audit plan line ticked, roadmap 4/61.

Documents only; no test reads the pin.

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

CHANGELOG.md

@@ -17,6 +17,12 @@ Format follows [Keep a Changelog](https://keepachangelog.com/en/1.1.0/); version
   `selfpost-backup -version` against it, and `release.yml` checks the stamp
   again on the image right before pushing it. Images already published are
   left as they are.
+- **The documents no longer promise an image that is not there.** README,
+  the guide and the compose file pinned `ghcr.io/mixeme/selfpost:2.4.1`, but
+  no 2.x image has been published (ghcr.io holds `1.0.0` and `1.3.0`). They
+  now say so and show how to build the image locally under the pinned name,
+  which Compose and `docker run` then use without pulling (audit 2026-10-12,
+  M6). The pin stays: the next publication makes it true.
 - **The e2e module is compiled on every push** (`test.yml`: `go vet` and
   `go test -c` in `test/e2e`), so a type error there no longer first shows
   up in `release.yml` after a release is published (audit 2026-10-12, M20).

README.md

@@ -106,6 +106,16 @@ One container, panel at `http://127.0.0.1:8080` — no reverse proxy, no TLS
 files, no compose files. Good for clicking through the UI on your machine;
 outbound mail will not reach the real internet without DNS, PTR, and port 25.
 
+> **The 2.x line is not published on ghcr.io yet** (the newest image there is
+> `1.3.0`). Until it is, build the image from this checkout under the name the
+> commands below and `deploy/docker-compose.yml` use; Docker then takes the
+> local image and pulls nothing:
+>
+> ```sh
+> docker build -f build/Dockerfile --build-arg VERSION=2.4.1 \
+>   -t ghcr.io/mixeme/selfpost:2.4.1 .
+> ```
+
 ```sh
 docker run --rm -d --name selfpost-try \
   -p 127.0.0.1:8080:8080 \

deploy/docker-compose.yml

@@ -18,6 +18,8 @@
 # The image tag below is FIXED on purpose: backup restore compares the manifest
 # version against the running binary's version, so ":latest" would make that
 # check meaningless. Bump the tag deliberately when you want to upgrade.
+# The 2.x line is not on ghcr.io yet: build it locally under this exact name
+# (README, Quick start) and Compose will use it without pulling.
 
 services:
   selfpost:

docs/audit-2026-10-12.md

@@ -555,7 +555,7 @@ has already run is never edited — the next file is added; the published
    test -c -o /dev/null .` (not `go test -run xxx`: `TestMain` would still
    run and bring up the stand). — **Haiku**
 - [x] **`.dockerignore` + `test/`** (L33). — **Haiku**
-- [ ] **The pin** (M6): old tags and images are not touched (owner,
+- [x] **The pin** (M6): old tags and images are not touched (owner,
    2026-10-12). The next publication through the fixed `release.yml` is the
    one the pin names; until then README/guide say that the current line is
    not yet published rather than name an image that is not there. — **Sonnet**

docs/development.md

@@ -280,7 +280,11 @@ they are.)
 
 1. Close `[Unreleased]` in [CHANGELOG.md](../CHANGELOG.md) and bump the pinned
    tag in [deploy/docker-compose.yml](../deploy/docker-compose.yml) (and any
-   local-trial image references) in the **same** release commit.
+   local-trial image references) in the **same** release commit. While no
+   image of the current line is published, README, guide § Fixed image tag
+   and the compose file's header say so and show the local build under the
+   pinned name; bump the version there too. The first publication of the
+   line removes those notes.
 2. Create and push git tag `vX.Y.Z` on that commit.
 3. Publish the GitHub Release for `vX.Y.Z` (not a draft).
 4. Workflow [release.yml](../.github/workflows/release.yml) builds, e2e-gates,

docs/guide.md

@@ -184,7 +184,18 @@ cat ./data/setup-token
 #### Fixed image tag
 
 `deploy/docker-compose.yml` pins an explicit version (`ghcr.io/mixeme/selfpost:X.Y.Z`),
-deliberately never `:latest`. The current pin is `2.4.1`. Intermediate
+deliberately never `:latest`. The current pin is `2.4.1`. **No 2.x image is
+published on ghcr.io yet** (the newest there is `1.3.0`); until one is, build
+it from the checkout under the pinned name, and Compose uses the local image
+instead of pulling:
+
+```sh
+docker build -f build/Dockerfile --build-arg VERSION=2.4.1 \
+  -t ghcr.io/mixeme/selfpost:2.4.1 .
+```
+
+`VERSION` must equal the tag: it is the version the backup check compares
+(see below). Intermediate
 CHANGELOG sections (`0.2.0`…`0.6.0`) record development cuts from before that
 image was published. Pinning matters because of the backup version check (see
 [Full backup and restore](#full-backup-and-restore)): the panel binary's

docs/roadmap.md

@@ -42,7 +42,7 @@ in `git log` and [CHANGELOG.md](../CHANGELOG.md).
 | from-header-binding | Hold a message's `From:` header against the application that sends it | shipped `2.4.0` | 9/9 | [plans/from-header-binding.md](plans/from-header-binding.md) |
 | panel-redesign | Panel redesign (accepted mockups, design contract) | shipped `2.0.0` | 27/27 | [plans/panel-redesign.md](plans/panel-redesign.md) |
 | schema-squash | Squash SQLite migrations into a 2.x baseline | built in panel-redesign (stage 1) | — | [plans/panel-redesign.md](plans/panel-redesign.md) |
-| audit-2026-10-12 | Follow-ups of the 2026-10-12 full-tree code audit, seven stages | agreed (2026-10-12: stage 0 first, then 1+2; the rest after) | 3/61 | [audit-2026-10-12.md](audit-2026-10-12.md) |
+| audit-2026-10-12 | Follow-ups of the 2026-10-12 full-tree code audit, seven stages | agreed (2026-10-12: stage 0 first, then 1+2; the rest after) | 4/61 | [audit-2026-10-12.md](audit-2026-10-12.md) |
 
 **Recommended order** (not binding; owner, 2026-10-09: feature order follows
 development convenience): **panel-redesign** shipped as `2.0.0` (2026-10-11) and