[argszero]

Closes #2685

What

Release v0.3.34 of EMRG.

Why now

The host asked for a new release on 2026-11-03 (18:23 local, session emrg-task), and the standing condition — every EMRG rant closed — holds: the queue reads 0 pending and 0 in progress, the last row having been completed on 2026-11-03 once its merge commit's master CI came back green on both legs.

master is 19 commits past the v0.3.33 tag. The installed copy on the host still reads 0.3.33, so none of those fixes — the batch-call reminder among them — has reached a runtime yet. A release is the only step that moves them.

Baseline

• Latest release: v0.3.33, published 2026-10-29T15:26:42Z, 11 assets, not a draft and not a prerelease (scripts/check-release-published.py reads OK).
• master at the time of the bump: 6f06efa0 — 19 commits past the tag.
• The bump rewrites all 8 version declarations to 0.3.34; tests/test_version_sync.py and scripts/bump-version.py --check prove they agree.

Acceptance

1. The bump PR merges on three approvals from three different cycles — never self-merged.
2. On the merged commit, scripts/check-release-tag.py v0.3.34 reads OK, and the tag exists nowhere before that point, so it is cut exactly once.
3. v0.3.34 is published as Latest — not a draft, not a prerelease — with the full asset set: macOS pkg plus the two AppImage files with their .zsync, the Windows installer and zip, and the Linux tarball.
4. The tag-triggered build-release.yml run is green on all four platform legs.
5. The macOS leg's signing and notarization succeed; that verification exists nowhere else.

[argszero]

✅ LGTM — cycle cyc20261103-182713

Version bump only: 8 files, +9 −9, every changed line a version string from 0.3.33 to 0.3.34.

Measured this cycle, on the tree a merge would produce (git merge-tree --write-tree 6f06efa0 eaca30bb = 0ed13290110a9bebbabdebd8ea7ca45139dbefb5): 8 files changed, 9 insertions, 9 deletions — no behaviour rides a bump.

check-merge-freshness.py 2686 reports FRESH: master is an ancestor of the head (ahead, behind_by=0) and the merge base IS master's tip 6f06efa0, so the green CI below describes exactly that landing tree. Both legs concluded green on run 41618974968: test 3m39s, test-windows 5m36s. PR reads MERGEABLE/CLEAN.

[argszero]

✅ LGTM — cycle cyc20261103-183416

Version bump only, re-measured this cycle on the tree a merge would produce rather than on the PR's page: merge base of origin/master and head eaca30bb is master's tip 6f06efa0, so git merge-tree --write-tree 6f06efa0 eaca30bb answers 0ed13290…, and git rev-parse eaca30bb^{tree} answers the same 0ed13290…. The green run therefore tested exactly the bytes a merge lands.

Diff: 8 files, +9 −9, every changed line a version string (0.3.33 → 0.3.34) across pyproject.toml, uv.lock, emrg/__init__.py, the two emrg/gui/package*.json and three packaging scripts. No behaviour rides a bump.

Both legs concluded green on run 41618974968 — test 3m39s, test-windows 5m36s — and check-merge-freshness.py 2686 reads FRESH with behind_by=0. Link reading check-issue-links.py exits 0: #2685 and #2686 name each other.

[argszero]

✅ LGTM — cycle cyc20261103-184438

Third and last vote on a version bump, re-measured on this cycle's own readings rather than on the PR page.

The landing tree is the head tree, byte for byte: the merge base of origin/master and head eaca30bb is master's tip 6f06efa0, so git merge-tree --write-tree 6f06efa0 eaca30bb answers 0ed13290… and git rev-parse eaca30bb^{tree} answers the same 0ed13290…. Both CI legs concluded green on that tree — run 41618974968, test 3m39s and test-windows 5m36s — and check-merge-freshness.py 2686 reads FRESH with behind_by=0, so the green run describes exactly the bytes a merge lands.

The diff is 8 files, +9 −9, and every changed line is a version string moving 0.3.33 to 0.3.34: pyproject.toml, uv.lock, emrg/__init__.py, emrg/gui/package.json and its lock, and three packaging scripts. No behaviour rides a bump.

PR reads MERGEABLE/CLEAN and check-issue-links.py exits 0 with #2685 and #2686 naming each other.