feat(updater): nightly builds and a stable/nightly update channel

Every master push publishes its artifacts as a prerelease of
4gray/iptvnator-nightly instead of the rolling test-master draft, with a
version of <next patch>-nightly.<commit date>.<run number> applied in
every build job. Settings → About gains an Update channel switch;
AppUpdateService re-points electron-updater per check (feed repository,
allowPrerelease, channel name, allowDowngrade reset) and reads release
notes from the repository the requested version belongs to. Channel
switches are forward-only: a nightly build stays until a newer stable
release exists.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

docs/architecture/release-pipeline.md

@@ -276,6 +276,85 @@ References: [AppImage desktop keys](https://docs.appimage.org/reference/desktop-
 [AppManager desktop parser](https://github.com/kem-a/AppManager/blob/v3.8.0/src/core/desktop_entry.vala),
 [AppManager updater](https://github.com/kem-a/AppManager/blob/v3.8.0/src/core/updater.vala).
 
+## Nightly channel
+
+Every push to `master` of `4gray/iptvnator` is also a nightly. The same
+`build-and-make.yaml` run that builds the matrix publishes its artifacts as a
+**prerelease of `4gray/iptvnator-nightly`** instead of the rolling
+`test-master` draft: a draft is invisible to anyone without write access and
+to electron-updater, while a published prerelease is what the desktop app's
+**Nightly** update channel installs. PR builds keep their `test-pr-<n>`
+drafts; tag builds are unaffected.
+
+**Version.** Each build job rewrites the `package.json` version before the
+frontend and backend builds and before electron-builder reads it
+(`tools/release/nightly-version.mjs --apply`):
+
+```
+0.23.0  →  0.23.1-nightly.20260915.1234
+           └ next patch ┘ └ commit date ┘ └ run number ┘
+```
+
+- Greater than the released `0.23.0`, so a stable user who switches channels
+  is offered it; smaller than `0.23.1` and `0.24.0`, so the next stable
+  release is offered to nightly users on either channel.
+- The run number only grows, so nightlies order correctly within a day.
+- electron-builder derives the updater channel files from the prerelease
+  tag: `nightly-mac.yml`, `nightly.yml`, `nightly-linux.yml`. The artifact
+  upload globs and the macOS metadata merge accept both names.
+- Every job derives the same value from the same inputs (commit date + run
+  number), so nothing is handed between jobs. The release job recomputes it
+  to name the tag `v<version>`.
+- The root `package.json` is an Nx `sharedGlobals` input, so the rewritten
+  version reaches the `web` and `electron-backend` bundles (which embed it)
+  instead of a cache hit built from the released version.
+- The base is the released version in `package.json`. In the short window
+  between a version bump commit and its tag, a nightly is numbered above the
+  upcoming release; the next nightly after the tag corrects that.
+
+**Publication** (steps at the end of the `create-release` job):
+
+1. `NIGHTLY_RELEASE_TOKEN` — a fine-grained PAT with *Contents: read/write*
+   on `4gray/iptvnator-nightly` — is required. Without it the run only warns;
+   `GITHUB_TOKEN` cannot write to another repository. The nightly repository
+   needs one commit on its default branch, because `gh release create`
+   creates the release tag there.
+2. The notes list the master commits since the previous nightly. That
+   nightly's source commit is read back from the `<!-- iptvnator-commit: … -->`
+   marker its own notes carry, then `compare` on the main repository (with
+   `GITHUB_TOKEN`) lists the range. A missing marker or a rewritten history
+   only drops the list.
+3. The release is created as a draft, assets are uploaded, then it is
+   published in one edit, so electron-updater never sees a release whose
+   channel file is still missing. Missing `nightly-mac.yml`,
+   `nightly.yml` or `nightly-linux.yml` fails the step instead.
+4. The release job is serialized per ref, but two master runs can finish out
+   of order. electron-updater takes the newest feed entry, so a nightly older
+   than the newest published one is dropped rather than published.
+5. Only the newest `NIGHTLY_KEEP_RELEASES` (20) nightlies are kept; older
+   ones are deleted together with their tags.
+
+**In the app.** `Settings.updateChannel` (`stable` / `nightly`, default
+`stable`) is a normal renderer setting mirrored into the main-process config
+by `SETTINGS_UPDATE` (`APP_UPDATE_CHANNEL`), because the startup check runs
+before the renderer exists. `AppUpdateService` re-points electron-updater on
+every check (`app-update-feed.ts`): the GitHub feed URL of the channel's
+repository, `allowPrerelease` only for nightly, the channel name (`nightly`,
+or the explicit `latest` for stable — the setter refuses `null` once set),
+and `allowDowngrade = false` reset afterwards, since assigning a channel
+silently enables downgrades and the constructor enables prereleases for any
+prerelease build. Release notes and the manual-install fallback (Linux
+without AppImage) read the channel's release list; notes for a nightly
+version always come from the nightly repository, so a nightly build on the
+stable channel still shows its own notes.
+
+Switching is forward-only on purpose: a nightly build stays installed until
+a newer stable release exists, because a downgrade could land on a release
+that does not understand the database schema a nightly migration already
+applied. Nightly users therefore accept that everything merged into master
+is de facto shipped — a migration on master can only be followed by another
+migration, never reworked.
+
 ## After verification
 
 Publishing the GitHub release is manual. That publication automatically