emrg: v0.3.34 never published, so the next release is 0.3.35 cut from a tree that has the AppImage fix #2691

What is wrong

master declares version 0.3.34 and tag v0.3.34 exists, but no v0.3.34 release was ever
published: gh release view v0.3.34 answers release not found, and the Build Release run
41625081155 that the tag triggered finished completed/failure after 22m07s. Its macOS arm64
package and its windows-x64 executable built fine; both Linux legs failed because
appimagetool now treats 0700 directories in the AppDir as a fatal error rather than a warning,
so the release job that publishes the assets was skipped.

That defect has its fix in #2690, which is not merged. Because the tag is already spent on a
build that cannot succeed, cutting the next release on the same commit would reproduce the same
failure: the version number has to move forward, and the tag has to name a tree that contains the
AppImage fix.

The consequence today is that the newest published release is v0.3.33
(2026-10-29T15:26:42Z, 11 assets) and the installed copy reads 0.3.33, so nothing merged since
then has reached a host.

What the release must satisfy

1. Every version declaration in the tree agrees on 0.3.35 — the eight sources
   scripts/bump-version.py rewrites, proved by tests/test_version_sync.py.
2. The release commit is cut on a master that contains the AppImage permission fix, so the
   Linux legs can pass. The fix is not in this bump; the bump waits for it.
3. Tag v0.3.35 is created only after that master state is reached, and it names a tree whose
   version is 0.3.35 (scripts/check-release-tag.py v0.3.35).
4. The published release is non-draft, non-prerelease, and carries the full 11-asset set for all
   four platforms, including the macOS package and both .zsync files, confirmed by
   scripts/check-release-published.py v0.3.35.
5. v0.3.34 is left alone as a tag that never produced a release. It is not deleted, moved or
   re-created, and no published version is rolled back, because nothing was published under it.