channels: the dev channel publishes on dev-rolling, so its tag stops shadowing the branch

The rolling dev release lived on a tag named `dev`, beside the branch
named `dev`. Once a clone had fetched tags, `git push origin dev` failed
with "src refspec dev matches more than one" (Scribe #2184, note #3042),
and every session had to know to spell out refs/heads/dev.

The channel is still `dev` everywhere a person sees it: the app's
setting, `install.sh --channel dev`, the stored pref. Only the release
tag moves, to `dev-rolling`, matching roundtable-android. `stable` has no
branch to collide with and keeps its name.

- packaging/channel-tag.sh is the one channel -> tag mapping CI reads:
  the publish steps in android.yml and desktop.yml, the manifest job,
  fetch-clients.sh and guard-forward.sh. guard-forward exits 2 on an
  unmapped channel instead of fetching an empty URL and passing.
- update.rs and install.sh carry their own copy because neither can run
  it; update.rs gains a test that no channel feed is named like a branch.
- tests/test_channel_tag.py runs the script: no tag is a branch name,
  dev is exactly dev-rolling, an unknown channel fails with no output.
- publish-release.sh titles the release "ThoughtSync dev (rolling)", so
  the tag name does not leak into what people read.

TEMPORARY bridge: desktop apps installed before this have
.../download/dev/latest.json compiled in. The dev manifest job sets
BRIDGE_TAG=dev, and write-manifest.sh writes the same latest.json to
the old `dev` release. Its URLs name dev-rolling assets, so those apps
update once into a build that reads the new tag. The bridge, and the old
release and tag, are removed once installed apps have crossed over.
Until then the push still needs the explicit refspec, as
ci-requirements.md now says.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DwoKYuw3qJmUUYsJeNherB

ci-requirements.md

@@ -409,18 +409,25 @@ the lockfile format and the picked versions identical to what CI would have
 chosen. Commit the result in the same change as the `Cargo.toml` edit — a
 manifest change pushed without it fails the gate.
 
-## Pushing: `dev` is both a branch and a tag
+## Channel releases: `dev-rolling` and `stable`
 
-`git push origin dev` fails in this repo:
+The two update channels are releases on fixed tags, because Fabled-Git has no
+`/releases/latest/download/<asset>` route and the updater needs a permanent URL.
+The **channel** is still called `dev` everywhere a person sees it; its **release
+tag** is `dev-rolling`. `packaging/channel-tag.sh` is the one mapping CI reads.
+`desktop/src-tauri/src/update.rs` and `desktop/packaging/install.sh` carry their
+own copy because neither can run it — change all three together.
 
-```
-error: src refspec dev matches more than one
-```
+The tag used to be `dev`, which shadowed the branch of the same name: once a clone
+had fetched it, `git push origin dev` failed with
+`error: src refspec dev matches more than one` (Scribe #2184). Never name a channel
+tag after a branch; `tests/test_channel_tag.py` and the `update.rs` tests fail if
+one is.
 
-The rolling update channel is a release on a **fixed tag named `dev`** (the tag
-never moves — Fabled-Git has no `/releases/latest/download/<asset>` route, so the
-updater needs a permanent URL). Once that tag is fetched locally, the short name
-`dev` resolves to both `refs/heads/dev` and `refs/tags/dev`. Fully qualify it:
+**Transitional, from 2026-09-10:** the old `dev` release still exists so desktop
+apps installed from it can update across — the manifest job writes `latest.json`
+to it too (`BRIDGE_TAG=dev` in `desktop.yml`). Until that release and its tag are
+deleted, fully qualify pushes:
 
 ```
 git push origin refs/heads/dev:refs/heads/dev