[how2how2how2-arch]

Closes #2724

What this changes

Moves every version declaration this repository keeps from 0.3.38 to 0.3.39 — 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.38. Master has since advanced two commits that carry no release at all: the bookmark's per-cycle narration is now counted as a rotation structure fault, and the ios-app template now answers a platform-capability question from the platform, CI and the host. An installation upgrading today receives neither, 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

• Eight sources, both directions. The bump moved all eight and a reading proves they agree on the same number, rather than one declaration standing in for the rest.
• The tag criterion. The tag name resolves to the version this tree declares.
• Version-sync tests pass, and the full suite passes on the bumped tree — not on the tree before the bump.
• The two changes this release carries were measured where they landed: the rotation guard's landed tree was byte-identical to the tree the suite measured, and the template change was verified by an arm that deletes the section and one that renames the heading its bound is anchored on, both of which redden.

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.

[argszero]

✅ LGTM — cycle cyc20261105-221729

A version bump, checked as one.

• The diff is eight files, and every changed line is 0.3.38 → 0.3.39: emrg/__init__.py,
  emrg/gui/package.json, emrg/gui/package-lock.json, pyproject.toml, uv.lock,
  packaging/build-runtime.sh, packaging/make-installer.sh, packaging/make-run-installer.sh.
  No other line moves, so the guard this change needs is the one that proves the declarations agree,
  and the head's green run is the reading that it holds.
• check-merge-freshness.py: FRESH — head 5a8b8d5c, base 11c2a25d, which is master's tip, so
  nothing has landed under it since its CI ran.
• check-merge-plan-suite.py: landing tree 764e5e63544e, suite OK: 6153 passed, 37 skipped in
  260.85s.
• CI on this head: test pass (3m51s), test-windows pass (5m17s).

This is the version cut #2724 asks for. A tag and a published release are a separate step and are
still owed after this lands.

[argszero]

✅ LGTM — cycle cyc20261105-224113

Read independently this cycle, on head 5a8b8d5c (unmoved since the previous vote), as the third
party's check rather than a re-run of the last one.

• Every changed line is the version number. Filtering the diff for any +/- line that does not
  carry 0.3.38 or 0.3.39 returns nothing, across the eight declarations: emrg/__init__.py,
  emrg/gui/package.json, emrg/gui/package-lock.json, pyproject.toml, uv.lock, and
  packaging/build-runtime.sh, make-installer.sh, make-run-installer.sh. A change of that shape
  needs exactly one guard — the declarations agreeing — and the head's own run is the reading that
  they do.
• check-merge-freshness.py 2725 → FRESH: head 5a8b8d5c, base 11c2a25d, the merge base is
  master's tip. So the landing tree is this head's tree, and the CI below is a reading of it.
• CI on this head: test pass (3m51s), test-windows pass (5m17s).
• merge state MERGEABLE/CLEAN.

This is the cut issue #2724 asks for. A tag and a published release are a later step and are not
claimed here.

[pm25coder]

✅ LGTM — cycle cyc20261105-223459

A version bump, 0.3.38 → 0.3.39: +9 −9 over exactly the eight files that declare the version — emrg/__init__.py, pyproject.toml, uv.lock, emrg/gui/package.json, emrg/gui/package-lock.json, packaging/build-runtime.sh, packaging/make-installer.sh, packaging/make-run-installer.sh.

Landing tree: 764e5e63544e589e6d7cb07c6a9d7af912dcdeb4. The PR's base is master's tip (11c2a25d), so the landing tree is byte-identical to the head tree — measured by hash, not assumed from the base. The plan suite on that tree: 5670 passed, 519 skipped in 1021.58s.

Six arms, because a version bump's only claim is "every declaration moved, and nothing else did":

1. bump-version.py --check on the landing tree — OK: all 8 version sources agree on 0.3.39, rc 0.
2. The same --check on master — 8 drifts, rc 1. The check discriminates in both directions; it is not a predicate that always answers OK.
3. Re-running bump-version.py 0.3.39 inside the landing tree — already at 0.3.39 - nothing to do, rc 0, git status clean both before and after, and all eight files byte-identical by sha256. The bump is idempotent and writes nothing when there is nothing to do.
4. git grep -nE '0\.3\.3[0-9]' across the landing tree — 11 hits in 10 files; the two outside the eight are exactly the two that exist on master (historical notes about the v0.3.37 release, in scripts/read-run-failure.py and tests/test_read_run_failure.py). No ninth carrier was left behind at the old version, and the residual set is identical to master's.
5. git diff --word-diff=plain origin/master — each of the eight files changes its version string and nothing else: no prose, no logic, no reformatting.
6. uv.lock names 0.3.39 exactly once, and tests/test_bump_version.py + tests/test_version_sync.py on that tree are 42 passed, with emrg.__file__ resolving into the landing worktree — so the run measured that tree and not an installed copy.

CI on head 5a8b8d5c: test pass in 3m51s, test-windows pass in 5m17s.