docs: the image tag list said something step 6 stopped being true

`:<git-sha>` is on `main` only now — a sha tag per dev push was a rollback
target nobody had ever pulled — and `:<version>` never existed as an image tag
after rule 145 was narrowed. Both were still documented.

`docs/android-distribution.md` also said `:dev`, `:latest` and `:<version>` all
ship a client, which is now two-thirds true and misses the more useful fact: the
channel IS the image you run, so a stable server serves a stable client. Worth
saying because until step 3 it was hard-wired to the dev release on every branch
and did the opposite.

This push is also the skip-if-exists verification. It touches neither client's
file set, so both `decide` jobs should report the channel already serving the
current version and skip a 6- and a 9-minute build — while the guard still runs
on that path (§6.3).

#3146

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

README.md

@@ -99,8 +99,10 @@ Then open `http://<host>:5000` and register — **the first account becomes the
   unset, a signing key is generated and persisted in the database (sessions survive restarts).
 - Uploaded images live under the `thoughtsync-data` volume at `/var/thoughtsync`.
 - The app waits for the database and runs migrations (`alembic upgrade head`) automatically on start.
-- **Image tags:** `:latest` (stable, built from `main`) · `:dev` (latest `dev` build) ·
-  `:<git-sha>` (immutable, for pinning / rollback).
+- **Image tags:** `:latest` (stable, built from `main`) · `:dev` (latest `dev`
+  build) · `:<git-sha>` on `main` only (immutable, the rollback unit). There are
+  no version-shaped tags: nothing pins one, and the build reports its own version
+  at `/api/config` and `/health`.
 - **Putting it on the public internet:** there are four things to do first — close
   registration, terminate TLS and forward `X-Forwarded-Proto`, stop publishing the app
   port, and back up the attachment volume as well as the database. See

docs/android-distribution.md

@@ -15,13 +15,19 @@ cannot talk to.
 
 **Normally: nowhere. It is already in the image.**
 
-CI fetches the newest published Android build into every server image it builds,
-so `:dev`, `:latest` and `:<version>` all ship a client. `docker compose pull &&
-docker compose up -d` delivers a new server and a new client together, and there
-is nothing to copy.
+CI fetches the published Android build into every server image it builds, so
+`:dev` and `:latest` both ship a client. `docker compose pull && docker compose
+up -d` delivers a new server and a new client together, and there is nothing to
+copy.
 
-A versioned image therefore carries the *newest* client rather than one pinned to
-that version. That is deliberate: the two negotiate a sync protocol version
+**The channel is a property of the image you run.** A `:dev` image bakes in the
+dev-channel APK, `:latest` the stable one — so pointing a phone at a stable
+server gets it a stable client, with no second place holding that decision. (Until
+M314 step 3 the fetch was hard-wired to the dev release on every branch, so a
+stable server served a dev client.)
+
+An image therefore carries the *newest* client on its channel rather than one
+pinned to a version. That is deliberate: the two negotiate a sync protocol version
 before they link, so a mismatch is caught by the handshake rather than by
 pinning.