ci: back-merge master into develop after every release

release-plz owns the workspace version and the changelog, and writes both on
master. Nothing carried either back, so develop still declared 14.1.2 five
releases after v14.1.2 shipped. Nightly builds the tip of develop, which meant
every nightly binary reported --version 14.1.2 against a released 18.0.0, and
the changelog on the branch the work happens on stopped at v14.1.2 too.

The job merges master whole rather than cherry-picking the bump, so the
changelog travels with it, and hangs off `release` rather than `binaries` so the
sync does not wait on six binary builds. develop never edits those lines itself,
which is what keeps the merge clean; a conflict fails the job rather than
resolving itself quietly. Nothing in the repository triggers on a push to
develop, so this neither loops back into the workflow nor spends a CI run.

RELEASE.md

@@ -29,10 +29,17 @@ Releases are automated by [release-plz](https://release-plz.dev). You do not run
      | `soulseek-rs-vX.Y.Z-aarch64-pc-windows-msvc.zip`       |                          |
 
    - rewrites `Formula/soulseek-rs.rb` in the `michel/homebrew-tap` repository so
-     `brew install michel/tap/soulseek-rs` picks up the new macOS and Linux archives.
+     `brew install michel/tap/soulseek-rs` picks up the new macOS and Linux archives,
+   - merges `master` back into `develop`, so the branch the work happens on carries the
+     new version and changelog rather than drifting behind them.
 
 Both crates always share one version, one tag, and one changelog — see `release-plz.toml`.
 
+The version lives in one place, `[workspace.package]` in the root `Cargo.toml`, and
+release-plz owns it. Do not edit it by hand on `develop`: the back-merge relies on
+`develop` never touching that line, and an edit there turns every release into a
+conflict.
+
 ## Nightly builds
 
 `.github/workflows/nightly.yml` builds the tip of `develop` at 02:17 UTC every