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