desktop: in-app updates, two channels, signed, fed by fixed-tag releases

There was no in-place update anywhere. The app never checked, downloaded or
applied anything, and the only published release predates the whole sync arc —
so `install.sh` would hand out a build with no sync in it. Installing from
per-run CI artifacts, which is what's been happening, is not something an
updater can point at: ephemeral, auth-gated, no stable URL.

Two channels, switchable in the app: `stable` follows tagged releases, `dev`
follows every green push.

The feed is a Fabled-Git release asset, not a ThoughtSync server route. This
reverses the lean recorded in task 1998, and the reason matters — a
server-hosted feed can only reach a desktop that has linked a server, and
local-first-with-no-server is the whole premise. An unlinked install has to be
able to update itself.

Each channel reads a `latest.json` on a release whose TAG NEVER MOVES.
That's forced, not stylistic: Forgejo has no /releases/latest/download/<asset>
route (verified — it 404s with no redirect), so "newest" cannot be named in a
URL. `dev` carries the rolling bundles; `stable` is a pointer release holding
only the manifest, whose URLs aim at the versioned release's assets, so nothing
is duplicated.

The manifest is written by a third job that runs after both bundle jobs. They
build in separate workspaces and neither can see the other's output, but one
manifest has to describe both platforms — generating it inside either job would
silently omit the other, and a missing platform reads to a user as "no update
available" rather than as a broken feed. It reads what actually landed on the
release, so it can never advertise a bundle that failed to upload.

Signing is gated on the secret existing, in the script rather than an `if:`
(the secrets context isn't reliably available to step conditions). No key means
no updater artifacts and no publish: a feed the app would refuse to verify is
worse than no feed, because it looks like it works. CI stays green until the
key lands.

On Linux the updater can only replace an AppImage — a deb or pacman install is
owned by its package manager and must never be overwritten underneath it. The
app detects that case up front and says so, instead of failing halfway through
with a permissions error nobody can read.

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

.forgejo/workflows/desktop.yml

@@ -73,8 +73,27 @@ jobs:
         working-directory: desktop/src-tauri
 
       # Frontend already built above; skip the beforeBuildCommand rebuild.
+      #
+      # createUpdaterArtifacts is applied only when a signing key exists (M10.9):
+      # tauri FAILS the build if it's asked to produce updater artifacts with no key,
+      # so making it conditional is what lets the pipeline stay green before the
+      # operator has added the secret. With the key present, each bundle gets a
+      # `.sig` beside it — the file the updater actually verifies against.
       - name: Tauri build (deb + AppImage)
-        run: cargo tauri build --config '{"build":{"beforeBuildCommand":""}}'
+        env:
+          TAURI_SIGNING_PRIVATE_KEY: ${{ secrets.TAURI_SIGNING_PRIVATE_KEY }}
+          TAURI_SIGNING_PRIVATE_KEY_PASSWORD: ${{ secrets.TAURI_SIGNING_PRIVATE_KEY_PASSWORD }}
+        run: |
+          updater='{}'
+          if [ -n "${TAURI_SIGNING_PRIVATE_KEY:-}" ]; then
+            echo "Signing key present — producing updater artifacts."
+            updater='{"bundle":{"createUpdaterArtifacts":true}}'
+          else
+            echo "No TAURI_SIGNING_PRIVATE_KEY — building unsigned, no updater artifacts."
+          fi
+          cargo tauri build \
+            --config '{"build":{"beforeBuildCommand":""}}' \
+            --config "$updater"
         working-directory: desktop/src-tauri
 
       # Tauri's AppImage bundles the build host's graphics/display libs
@@ -135,6 +154,28 @@ jobs:
           GITHUB_TOKEN: ${{ github.token }}
         run: bash desktop/packaging/publish-release.sh
 
+      # The rolling DEVELOPMENT channel (M10.9): a release whose tag never moves, so
+      # the updater has a permanent URL to read — Forgejo has no
+      # /releases/latest/download/<asset> route, so "newest" can't be named in a URL.
+      #
+      # Gated on the signing key INSIDE the script rather than with an `if:`, because
+      # the secrets context isn't reliably available to step conditions. Publishing
+      # bundles the app would then refuse to verify is worse than publishing nothing:
+      # it looks like a working feed.
+      - name: Publish to the dev channel
+        if: github.ref == 'refs/heads/dev'
+        env:
+          GITHUB_TOKEN: ${{ github.token }}
+          TAURI_SIGNING_PRIVATE_KEY: ${{ secrets.TAURI_SIGNING_PRIVATE_KEY }}
+          RELEASE_TAG: dev
+          RELEASE_PRERELEASE: "true"
+        run: |
+          if [ -z "${TAURI_SIGNING_PRIVATE_KEY:-}" ]; then
+            echo "No TAURI_SIGNING_PRIVATE_KEY — skipping the dev channel publish."
+            exit 0
+          fi
+          bash desktop/packaging/publish-release.sh
+
   # Windows installer, CROSS-COMPILED from Linux — there is no Windows build host.
   # A Windows container can't run on a Linux host (containers share the host
   # kernel), so cross-compiling is the only route without Windows hardware:
@@ -200,3 +241,69 @@ jobs:
         env:
           GITHUB_TOKEN: ${{ github.token }}
         run: bash desktop/packaging/publish-release.sh
+
+      # The rolling DEVELOPMENT channel (M10.9): a release whose tag never moves, so
+      # the updater has a permanent URL to read — Forgejo has no
+      # /releases/latest/download/<asset> route, so "newest" can't be named in a URL.
+      #
+      # Gated on the signing key INSIDE the script rather than with an `if:`, because
+      # the secrets context isn't reliably available to step conditions. Publishing
+      # bundles the app would then refuse to verify is worse than publishing nothing:
+      # it looks like a working feed.
+      - name: Publish to the dev channel
+        if: github.ref == 'refs/heads/dev'
+        env:
+          GITHUB_TOKEN: ${{ github.token }}
+          TAURI_SIGNING_PRIVATE_KEY: ${{ secrets.TAURI_SIGNING_PRIVATE_KEY }}
+          RELEASE_TAG: dev
+          RELEASE_PRERELEASE: "true"
+        run: |
+          if [ -z "${TAURI_SIGNING_PRIVATE_KEY:-}" ]; then
+            echo "No TAURI_SIGNING_PRIVATE_KEY — skipping the dev channel publish."
+            exit 0
+          fi
+          bash desktop/packaging/publish-release.sh
+
+  # The updater manifest, written AFTER both bundle jobs — they run in separate
+  # workspaces and neither can see the other's output, but one latest.json has to
+  # describe both platforms. Building it inside either job would silently omit the
+  # other, and a missing platform reads to a user as "no update available" rather
+  # than as a broken feed.
+  #
+  # Reads what actually landed on the channel release, so it can never advertise a
+  # bundle that failed to upload.
+  manifest:
+    name: Update manifest
+    needs: [build, windows]
+    if: github.ref == 'refs/heads/dev' || startsWith(github.ref, 'refs/tags/v')
+    runs-on: python-ci
+    container:
+      image: git.fabledsword.com/bvandeusen/ci-tauri:1.97
+    steps:
+      - uses: actions/checkout@v6
+
+      - name: Write and publish latest.json
+        env:
+          GITHUB_TOKEN: ${{ github.token }}
+          TAURI_SIGNING_PRIVATE_KEY: ${{ secrets.TAURI_SIGNING_PRIVATE_KEY }}
+        run: |
+          if [ -z "${TAURI_SIGNING_PRIVATE_KEY:-}" ]; then
+            echo "No TAURI_SIGNING_PRIVATE_KEY — nothing was signed, so there is no"
+            echo "manifest to write. Add the secret to enable in-app updates."
+            exit 0
+          fi
+          # The version the bundles carry, read from the crate rather than guessed.
+          version="$(grep -m1 '^version' desktop/src-tauri/Cargo.toml | sed -E 's/.*"([^"]+)".*/\1/')"
+          if [ "${GITHUB_REF_NAME}" = "dev" ]; then
+            export RELEASE_TAG=dev
+            export RELEASE_NOTES="Development build from ${GITHUB_SHA}"
+            APP_VERSION="$version" bash desktop/packaging/write-manifest.sh
+          else
+            export RELEASE_TAG="${GITHUB_REF_NAME}"
+            export RELEASE_NOTES="ThoughtSync ${GITHUB_REF_NAME}"
+            # Twice: once onto the versioned release itself, and once onto the
+            # permanent `stable` pointer the app actually reads. Same manifest both
+            # times — its URLs point at the versioned assets either way.
+            APP_VERSION="$version" bash desktop/packaging/write-manifest.sh
+            APP_VERSION="$version" MANIFEST_TAG=stable bash desktop/packaging/write-manifest.sh
+          fi