docs: pin the release dry run to a branch carrying the Tauri workflow

docs/release-process.md

@@ -123,17 +123,30 @@ must equal the asset names exactly.
 A dry run creates a **draft** release, which does not show up on the
 public Releases feed and does not reach any client, legacy or Tauri.
 
-1. Pick a throwaway tag with a suffix, like `v0.0.0-test`. The suffix
-   keeps the tag push from starting a publishing run; never use a plain
-   `vX.Y.Z` tag for a dry run, because pushing it publishes a release
-   marked latest.
-2. On a scratch branch, set `Cargo.toml` `version` to `0.0.0-test`, run
-   `cargo build` locally to refresh `Cargo.lock`, and commit both files.
-   The release jobs build with `--locked`, so a stale `Cargo.lock` fails
-   them before any draft exists. The tag check also runs for drafts, so
-   the tag must point at a commit whose `Cargo.toml` version matches it.
+1. Pick a throwaway tag with a suffix, like `v0.0.0-test`. The Tauri
+   `release.yml` triggers tag pushes only on plain `vX.Y.Z` tags and
+   refuses a suffixed tag outside a dispatch run, so the suffix keeps
+   the tag push from starting a publishing run. That guard exists only
+   in commits that carry the Tauri `release.yml`: the Win32
+   `release.yml` it replaced triggers on `v*.*.*`, suffix included, and
+   publishes a non-draft release that GitHub marks latest. Never use a
+   plain `vX.Y.Z` tag for a dry run, because pushing it publishes a
+   release marked latest.
+2. Cut a scratch branch from a commit that contains the Tauri
+   `release.yml`: the Tauri port branch before it merges, `main` after.
+   On it, set `Cargo.toml` `version` to `0.0.0-test`, run `cargo build`
+   locally to refresh `Cargo.lock`, and commit both files. The release
+   jobs build with `--locked`, so a stale `Cargo.lock` fails them
+   before any draft exists. The tag check also runs for drafts, so the
+   tag must point at a commit whose `Cargo.toml` version matches it.
 3. Tag that commit and push the tag, then start the "Release" workflow
-   from the Actions tab (`workflow_dispatch`) with that tag as input.
+   (`workflow_dispatch`) from the scratch branch with that tag as input:
+   in the Actions tab, select the scratch branch under "Use workflow
+   from", or run
+   `gh workflow run release.yml --ref <scratch-branch> -f tag=v0.0.0-test`.
+   The default ref is `main`, which runs whatever `release.yml` `main`
+   holds; before the merge that is the Win32 pipeline, which builds one
+   exe and no `latest.json`, so the check in step 4 cannot pass.
 4. Check the draft: it must hold exactly the six assets in the table
    above (with `0.0.0-test` as the version), and `latest.json` must list
    only `windows-x86_64` and `linux-x86_64`, with URLs equal to the
@@ -144,7 +157,9 @@ public Releases feed and does not reach any client, legacy or Tauri.
 
 If a Tauri release is broken in the field, publish the Win32 sources
 again under a higher version with the "Release legacy" workflow
-(`release-legacy.yml`):
+(`release-legacy.yml`). GitHub dispatches a workflow only once its
+file is on the default branch, so this workflow, and a dry run of it,
+is available only after the Tauri port merges into `main`:
 
 1. Pick a version `X.Y.Z` higher than every release in the field, so
    every client sees it as an update.