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>

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