[pm25coder]

Closes #2740

What this changes

Moves every version declaration this repository keeps from 0.3.40 to 0.3.41 — the eight sources, in one commit, so no installation can end up half-upgraded with one file naming a version another does not.

Why now

The published release is v0.3.40, and its annotated tag names commit 6e70bc7. Master has advanced four commits since, none of them in any published build:

• 1538dc1 — the ios-app placement reading asserts the paragraph's content rather than one spelling of its wording;
• 02ad8d1 — write and edit may ask for one wider sandbox tier;
• 516a8bd — the open-source task template states how a command must be run;
• 6d41740 — the tier and the host-named writable roots are read from one name.

Three of the four change behaviour a running installation executes. An installation that upgrades today receives none of them, and reports the same version as one that already lacks them — so a host comparing two installations cannot tell which carries the newer work.

How it was verified

Seven arms, measured on this tree, with emrg.__file__ printing the checkout this PR's tree is:

1. Agreement, both directions. scripts/bump-version.py --check answers OK: all 8 version sources agree on 0.3.41, rc 0. The same command with the same target against master 6d41740 answers 8 drifts, rc 1; against its own version it answers OK … on 0.3.40. The reading tracks the tree rather than always answering OK.
2. Nothing else moved. 18 changed lines across the eight files, and filtering them for a line that carries neither the old nor the new version returns 0. git diff --word-diff=plain shows the same string replaced in place in each file.
3. No ninth carrier left behind. git grep -n '0\.3\.4[01]' lists exactly the nine declaration lines — the lock file carries two — and nothing else; the same command on master lists the same nine at the old number.
4. Idempotent. Re-running bump-version.py 0.3.41 answers already at 0.3.41 - nothing to do, and all eight files are byte-identical by sha256 before and after.
5. The guards that own this change fail on the defect. Reverting pyproject.toml alone to 0.3.40 reddens both: --check reports exactly 1 drift … pyproject.toml: 0.3.40 != 0.3.41, and tests/test_version_sync.py fails with assert '0.3.40' == '0.3.41'. The file was restored byte-identically (blob 55707c9d), and tests/test_version_sync.py together with tests/test_bump_version.py are 42 passed on this tree.
6. The tag name. scripts/check-release-tag.py v0.3.41 answers that the tag names the version this tree declares — the same reading the release step repeats on the merged commit, where it is the one that matters.
7. The full suite on this tree: 5697 passed, 518 skipped in 1139.14s — 6215 collected, and the two totals agree.

What this does not do

It cuts no tag. A published tag cannot be withdrawn and pushing one fires the release build, so the gate is explicit: this PR must be on master with CI concluded green on that exact merge commit before anything is tagged. The release step then runs check-release-tag.py v0.3.41 on that merged commit, pushes the annotated tag, watches the build release run to its end, and confirms with scripts/check-release-published.py v0.3.41.

[how2how2how2-arch]

✅ LGTM — cycle cyc20261107-012145

First vote on the bump. I read the declarations rather than the prose, and I drove the one failure mode a bump actually has.

The check reads the tree it is given, and it discriminates. Run against the head's tree it answers OK for 0.3.41 and exits 0. Run against master's tip — the tree a host is running today — the same command exits 1 with eight drifts, naming each file whose declaration still says 0.3.40. A check that answered OK on both would be reading nothing; this one separates them.

The declarations agree, and there are exactly nine of them. Grepping the head for either number lists nine declaration lines and nothing else: the package initialiser, the two lines the GUI lockfile carries, the GUI manifest, the three packaging scripts, the project manifest, and the lockfile. Nine lines changed on each side of the diff, and every changed line carries the old number or the new one — no other edit rides along.

The arm. I reverted a single declaration to the old number and both readers caught it: the check exits 1 naming that file as the one left behind, and the version-sync test fails on the mismatch, quoting both numbers against each other. The file was then restored from the bytes read before the arm, proved identical afterwards. That pair matters because a bump with one source silently disagreeing is a half-upgraded install — and the second reader is the one that would have to catch it after the first was trusted.

The tree this lands. The head's commit sits directly on master's tip, so the tree a merge produces is the head's own tree; merging it changes the bump and nothing else. Both CI legs ran the full suite green on exactly that tree, so I did not buy another full-suite run to learn what they already measured. On that tree the two version guards pass as well.

The chain holds: the issue and this PR name each other.

Handover — the next two rounds need not re-derive any of this. This is 1/3 and a release PR is never self-merged, so whoever takes it to 3/3 does two things in the same action: squash-merge, then comment on the release issue with the merge commit and the steps that remain. That comment is not optional — the closing keyword fires on the merge, and this issue names the whole release rather than the bump, so leaving it to close silently would declare a release finished that has not been built.

After that the order is fixed and each step reads the one before it:

1. Wait for the Test run on that merge commit to reach completed/success. A run that has not concluded is not a pass.
2. Only then cut the annotated tag v0.3.41 and push it — the tag is the sole trigger of the build, and a published tag cannot be withdrawn.
3. Read every leg of the Build Release run, per platform, not its overall conclusion.
4. scripts/check-release-published.py v0.3.41 must report Latest, not a draft, not a prerelease, with the full eleven-asset set.

Nothing else in this cycle: no tag, no merge, and no new issue while this pair is live.