Actually offer a preview the release it precedes, and fix two more gaps

An Opus review of the previous commit found its headline claim didn't
hold: a preview and the release it precedes compute to the identical
numeric version by construction, but check_for_updates compared with a
strict `>` against the bare CARGO_PKG_VERSION (never the suffixed display
string), so `(0,4,13) > (0,4,13)` is false and the release was never
offered. Plain semver ordering doesn't make a `-preview.<sha>` suffix sort
below the same numeric release on its own here, since the comparison
never sees the suffix at all.

pick_update now takes is_preview_build, derived from whether
TRIPLE_C_BUILD_SUFFIX was baked in, and relaxes that one comparison to
`>=` — so "a release exists at my own number" reads as an update. A
production build still requires strictly newer.

Also: ported build-app.yml's `git tag --points-at HEAD` guard into the
preview version computation. Without it, workflow_dispatch (which this
workflow allows on main, not just PR builds) run on a commit a release
was already cut from would compute one past that release — reintroducing
"preview outranks production" through the manual-dispatch door. And
corrected two comments that claimed the prerelease filter was currently a
no-op: backfill-releases.yml mirrors every Gitea release to GitHub
unfiltered, prerelease flag included, so it's real defence-in-depth
against a dispatched backfill leaking a preview release, not a no-op.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FGjXq6fqtAFHdbhk4f3PfZ

.gitea/workflows/build-app-preview.yml

@@ -43,13 +43,18 @@ name: Build App (Preview)
 # prunes previous previews itself, keeping the newest few. Bundles are ~130 MB a
 # release; the point of a preview is the build you are testing now.
 #
-# Nothing here reaches GitHub: `build-app.yml` is the only workflow that
-# mirrors a release there, and it does so inline, gated on `prerelease: false`
-# — a preview release is never a candidate. (The previous mechanism here,
-# `sync-release.yml`, was `workflow_dispatch`-only and read
+# A preview release is not meant to reach GitHub. `build-app.yml`'s inline
+# mirror never sees one (it only runs for its own `push`-triggered release),
+# but `backfill-releases.yml` pulls every Gitea release unfiltered and would
+# faithfully forward a preview's `prerelease: true` if it were ever dispatched
+# while one existed — so `GitHubRelease::prerelease` in `update_commands.rs`
+# is real defence, not a no-op, even though the `preview-<sha>` tag shape
+# (never valid semver) already blocks it independently. (The previous
+# mechanism here, `sync-release.yml`, was `workflow_dispatch`-only and read
 # `gitea.event.release.*` fields that are only ever populated by a `release`
 # trigger, so it could never have actually run; deleted rather than fixed,
-# since build-app.yml's inline mirror already does its job. See triple-c#32.)
+# since build-app.yml's inline mirror already does what it was meant to do
+# for real releases. See triple-c#32.)
 
 env:
   GITEA_URL: ${{ gitea.server_url }}
@@ -115,15 +120,37 @@ jobs:
           # Reading the same `v${MAJOR_MINOR}.*` tags (including the `-mac`
           # / `-win` suffixed ones a partially-published release can leave
           # behind) means a preview built right before a release computes the
-          # exact number that release is about to take — so semver already
-          # orders `0.4.12-preview.<sha> < 0.4.12`, and a preview user is
-          # offered the real release the moment it ships. See triple-c#32.
+          # exact number that release is about to take — e.g. `0.4.13` for
+          # both. That makes the two numerically *equal*, not "preview less
+          # than release" — plain semver ordering does not make a
+          # `-preview.<sha>` suffix sort lower on its own here, because
+          # `check_for_updates` compares against the bare, stripped
+          # `CARGO_PKG_VERSION`, never the suffixed display string. What
+          # closes the loop is `update_commands.rs`'s `is_preview_build`
+          # check, which relaxes that one comparison to `>=` specifically so
+          # "a release exists at my own number" reads as an update. See
+          # triple-c#32.
           HIGHEST=$(git tag -l "v${MAJOR_MINOR}.*" \
             | grep -E "^v${MAJOR_MINOR}\.[0-9]+(-mac|-win)?$" \
             | sed -E "s/^v${MAJOR_MINOR}\.([0-9]+).*/\1/" \
             | sort -n | tail -1 || true)
 
-          if [ -n "$HIGHEST" ]; then
+          # Mirrors build-app.yml's own `EXISTING` guard: this workflow is
+          # also `workflow_dispatch`-able on `main`, not just PR-triggered, so
+          # HEAD can be a commit a release was already cut from. Without this,
+          # dispatching a preview there would compute `HIGHEST + 1` — one past
+          # that release — and produce exactly the "preview outranks
+          # production" failure triple-c#32 was filed over, just reintroduced
+          # through the manual-dispatch door instead of the automatic one.
+          EXISTING=$(git tag --points-at HEAD \
+            | grep -E "^v${MAJOR_MINOR}\.[0-9]+$" \
+            | sed -E "s/^v${MAJOR_MINOR}\.([0-9]+)$/\1/" \
+            | sort -n | tail -1 || true)
+
+          if [ -n "$EXISTING" ]; then
+            echo "HEAD is already tagged v${MAJOR_MINOR}.${EXISTING} — matching it"
+            PATCH="${EXISTING}"
+          elif [ -n "$HIGHEST" ]; then
             echo "Highest patch already used on this line: ${HIGHEST}"
             PATCH=$((HIGHEST + 1))
           else