Point desktop updates at the Gitea release feed

The updater now resolves the newest non-draft desktop-v* release through the
Gitea API at check time (J621_UPDATE_REPO, lowercase because the API path is
case-sensitive), picks the platform's latest*.yml asset and uses that release
as a generic electron-updater feed; J621_UPDATE_URL still overrides
everything. Verified against the live API: release picked, yml fetched,
artifact HEAD 200.

electron-builder's publish.url is now metadata only (still needed so the
build emits latest*.yml). Docs updated: CD release assets are the feed, the
website /desktop/ feed only matters for installs before 0.1.2.

deploy/README.md

@@ -145,9 +145,12 @@ Build the desktop installers without publishing anything:
 ```
 
 Hand the files out or attach them to a Gitea release manually — the script
-prints sizes and SHA-256 sums for the release notes.
+prints sizes and SHA-256 sums for the release notes. The release assets are
+also the desktop update feed; the app resolves the newest `desktop-v*`
+release on Gitea at check time (see `desktop/README.md`).
 
-Push the desktop builds and their update metadata to the frontend's feed:
+The frontend's `/desktop/` feed is optional now — kept for manual downloads
+and for installs older than 0.1.2. To publish it:
 
 ```bash
 ./push_desktop.sh            # build Linux packages + copy the feed to jakerasp
@@ -160,19 +163,13 @@ The remote copy defaults to `jakerasp:/home/jake/servers/J621`, or
 `$J621_DESKTOP_FEED_HOST` when set. Artifacts land in `deploy/data/desktop/`,
 which the frontend nginx mounts read-only and serves at `/desktop/`. The
 remote copy uses rsync when both ends have it, tar over ssh when the server
-does not. The desktop app's "Check for updates…" menu item reads
-`latest-linux.yml` / `latest.yml` from there (see `desktop/README.md`).
-Backend-only composes have no frontend, so no feed.
+does not. Backend-only composes have no frontend, so no website feed.
 
 The manual **CD** workflow (Actions tab) builds the desktop packages on the
 runner and attaches them plus the update metadata to the Gitea release
-`desktop-v<version>`; it does not touch the live feed, because that is
-runtime state on the deploy host and CI has no SSH key for it. After a CD run,
-publish the feed from a machine that can reach the deploy checkout:
-
-```bash
-./push_desktop.sh --no-build --local   # or without --local to also copy it
-```
+`desktop-v<version>`; that is what the desktop updater reads. The website feed
+is not touched by CI (runtime state on the deploy host, no SSH key there); use
+`push_desktop.sh` when it needs refreshing for old installs.
 
 ## Scheduled jobs
 

deploy/push_desktop.sh

@@ -1,11 +1,12 @@
 #!/bin/bash
-# Build the J621 desktop packages and publish them to the update feed.
+# Build the J621 desktop packages, optionally publish them to the website
+# feed.
 #
-# Locally the feed is deploy/data/desktop, which the frontend nginx mounts
-# read-only and serves at /desktop/. With --host the same directory is also
-# copied to a remote deploy checkout (rsync, or tar over ssh when the server
-# has no rsync). electron-updater reads latest-linux.yml / latest.yml from
-# there; the feed URL comes from desktop/electron-builder.yml.
+# Desktop updates no longer depend on this: the app resolves the newest
+# `desktop-v*` release on Gitea at check time (see desktop/README.md). This
+# script builds the packages and can copy them to deploy/data/desktop, which
+# the frontend nginx mounts read-only and serves at /desktop/ for manual
+# downloads and for pre-0.1.2 installs.
 #
 # Usage: ./push_desktop.sh [--win] [--no-build] [--local] [--host user@server:/path]
 #   --win       also cross-build the Windows NSIS installer (needs wine)