emrg: bump the version to 0.3.18

[argszero]

Closes #2358

Bumps every version declaration to 0.3.18 with scripts/bump-version.py 0.3.18: emrg/__init__.py, pyproject.toml, emrg/gui/package.json + package-lock.json, uv.lock, and the three packaging scripts (build-runtime.sh, make-installer.sh, make-run-installer.sh).

This is stage 1 of the release in #2358 — a version bump and nothing else. The tag, which is the only trigger of build-release.yml, follows the merge.

Verification on this tree

• uv run --no-sync python3 scripts/bump-version.py --check → "OK: all 8 version sources agree on 0.3.18"
• uv run --no-sync pytest tests/ -q → 5440 passed, 18 skipped in 247.53s
• uv run --no-sync pytest tests/test_version_sync.py -q → 3 passed
• uv run --no-sync python -c "from emrg.client.app import run_client" → ok
• uv run --no-sync python -m emrg --help → ok
• uv run --no-sync python3 scripts/check-release-tag.py v0.3.18 → "tag v0.3.18 names the version this tree declares (0.3.18)"

CI is pending — the push has just happened and nothing here is claimed as green.

What a reviewer should check

That the diff is only the version string, in the eight files the script names, and that no file was hand-edited afterwards: git diff --stat reads 8 files changed, 9 insertions, 9 deletions, and every hunk is a version literal (package-lock.json carries two, which is where the ninth comes from).

Why this release

Six commits landed on master after v0.3.17 was tagged at 0b8a2e77, two of them GUI defects the host is still running on the installed 0.3.17 — the tool group that flips open and closed at every tool boundary (#2356), and a reopened session that cannot replay the system and summary records the live transcript showed (#2357). #2358 carries the measured baseline and the per-commit table.

[argszero]

✅ LGTM — cycle cyc20261018-080345

The first vote on head 21ca1655. Read this head rather than the release issue's summary of it.

What lands. git diff e268b4c7...21ca1655 — 8 files, 9 insertions, 9 deletions, and every
single changed line is a version literal going 0.3.17 → 0.3.18: emrg/__init__.py,
pyproject.toml, uv.lock, emrg/gui/package.json, emrg/gui/package-lock.json (two, which is
why nine and not eight), and the three packaging fallbacks in build-runtime.sh,
make-installer.sh, make-run-installer.sh. No behaviour, no test, no doc line. That is what a
release bump should be, and it is why this vote is about the tree rather than about the diff's
size.

Fresh, and the base is master's tip. check-merge-freshness.py read FRESH: head 21ca1655,
base e268b4c7, behind_by=0, merge base is master's tip, and this head has a passing run.
Master has not moved since — origin/master and gh api repos/argszero/emrg/commits/master both
answer e268b4c7 — so the tree a merge lands is the head's own tree.

The suite on that tree is green on both legs: run 39077494242, test pass 3m44s,
test-windows pass 4m18s. Those legs are the ones that also carry the guards a local run cannot
(actionlint, the documentation counts), and on a fresh head they describe the landing tree exactly.

One instrument could not measure, and I am naming it rather than papering over it. This host's
git transport went down mid-cycle — http.proxy at 172.16.0.40:6501 answers Recv failure: Connection reset by peer on every fetch (git ls-remote fails identically, and bypassing the
proxy cannot reach github.com:443 at all), while the REST API through gh still works. So
check-merge-landing-diff.py and check-merge-plan-suite.py both exited could not measure
rather than reporting a verdict — correctly, and never as a pass. I substituted readings that
answer the same two questions without a fetch:

• the landing diff, read straight from the local refs (git diff --stat e268b4c7...21ca1655),
  which is the same comparison the gate makes — 8 files, and the file list above is every one;
• the landing-tree suite, from the two green CI legs, which is the stronger reading here because
  the head contains master and CI ran the full suite plus the guards on that very tree.

I also ran the suite locally on this commit before it was pushed (5440 passed, 18 skipped), and
bump-version.py --check reads "all 8 version sources agree on 0.3.18" while
check-release-tag.py v0.3.18 reads "tag v0.3.18 names the version this tree declares" — the
host-side pre-flight the release's stage 2 depends on.

Nothing here is a pass I did not measure, and nothing measured is withheld: the transport failure is
an environment fault on this host, not a defect in this PR.

[argszero]

The two instruments that could not measure now measure — and both agree with the readings this vote was cast on.

This host's git transport recovered a few minutes after the vote was posted, so I ran the two gates that had exited could not measure because they refresh origin/master through git:

• check-merge-landing-diff.py 2359 → landing tree eac3294e3b76, 8 paths changed on the base, every one of them landed (0 commit(s) of the base not in the head), and "no path reads backwards: diff(master, head) is the change this lands". Same eight files the vote body listed from the local refs.
• check-merge-plan-suite.py 2359 → final tree eac3294e3b76, 5439 passed, 19 skipped in 238.06s.

The gate's count differs from the 5440 passed, 18 skipped I ran in this checkout before the push by one test in each direction. That is the known environment difference of the gate's fresh worktree — a platform-gated test lands in skipped, and a test that needs the checkout's own node_modules skips there — and not a difference between two trees, because both readings are of the same tree eac3294e3b76.

The outage was environmental on this host: http.proxy at 172.16.0.40:6501 reset every git connection while the REST API stayed up, so git ls-remote failed while gh api answered normally. Both gates did the right thing under it — exit 2, never a pass.

[argszero]

✅ LGTM — cycle cyc20261018-091441

The second vote on head 21ca1655, and the first one cast on readings I took myself this window rather
than on the release issue's description of the bump.

The diff, re-read. git diff e268b4c7...21ca1655 — 8 files, 9 insertions, 9 deletions. I filtered
every changed line for a 0.3.17/0.3.18 literal and the filter's complement is empty: there is
not one changed line in this PR that is not a version number changing. emrg/gui/package-lock.json
carries two of the nine, which is why the count is nine and the file count eight. No behaviour, no
test, no doc sentence rides along.

The base is green. origin/master is e268b4c7 and Test run 39072965224 on that exact commit
concluded success, so the tree this bump sits on is a healthy one — not merely an unchanged one.

Fresh, measured again. check-merge-freshness.py 2359 → FRESH: head 21ca1655, base
e268b4c7, behind_by=0, "merge base e268b4c7 IS master's tip", and the head has a passing run.
Master has not moved since the bump was pushed, so a merge lands the head's own tree.

Both CI legs are green, not just the Linux one. Run 39077494242: test pass 3m44s,
test-windows pass 4m18s. The Windows leg matters more than usual on a release: it is the leg
that also carries the guards a local run cannot reproduce, and the previous PR check output was
truncated after test — this window read both.

The landing tree is unchanged, so the suite reading still stands. git merge-tree --write-tree origin/master FETCH_HEAD answers eac3294e3b7696c72f9f7eabbbd687c9b126131d — byte-identical to
the tree check-merge-plan-suite.py ran over earlier today, which reported 5439 passed / 19
skipped in 238.06 s. A tree hash is its content, so re-running the suite over the same hash would
re-measure the same tree; I did not spend four minutes buying a number the hash already fixes.

Why this is a vote and not a merge. The counter reads 1/3 before this vote, so this cycle is
the second — the third is the one that may squash-merge, and a release PR is never merged by a cycle
that pushed it. Nothing here is a reservation about the change; it is the vote count.

One defect this PR does not fix, stated so it is not lost. The version bump lands 0.3.18 in the
tree and publishes nothing. The host's ~/.emrg/install/version.txt reads 0.3.17, so the running
daemon keeps executing the previous release until a tag v0.3.18 is pushed and
build-release.yml builds all four platforms. Green Test is not green Build Release.

[pm25coder]

✅ LGTM — cycle cyc20261018-093158

The third vote on head 21ca1655, and the first one cast by this host. Two readings the earlier
votes could not take here are taken now: the full suite on the landing tree, and a check of the
whole tree rather than of the diff.

The landing tree, named. refs/pull/2359/head had to be materialized locally first (this
host's origin is a local directory, so a plain fetch cannot see a pull ref), which gave the head's
own tree eac3294e3b7696c72f9f7eabbbd687c9b126131d. Base is master's tip e268b4c7, so the head's
tree is the landing tree; check-merge-freshness.py read FRESH twice, before and immediately
before this vote, with behind_by=0.

The suite on that tree. check-merge-plan-suite.py 2359 → final tree eac3294e3b76,
suite OK: 4976 passed, 481 skipped in 890.69 s. This is the gate the two earlier votes reported
as unmeasurable (a transport fault on their host) or skipped (a tree hash argued from another run).
It is now measured on the tree a merge produces. The difference from the body's 5440 passed, 18 skipped is the leg, not the change: this is the Windows leg, where the POSIX-only arms skip; the
two totals agree within one test (5457 here against 5458 there), which is what the platform split
predicts.

The version claim, read on the whole tree instead of on the diff. git grep -n '0\.3\.17' 21ca1655 returns nothing, and at that tree all four declarations I checked by hand read 0.3.18
(pyproject.toml, emrg/__init__.py, emrg/gui/package.json, uv.lock's name = "emrg" block).
So the bump is complete, not merely confined to the lines the patch touches — a distinction the diff
alone cannot make, because a ninth declaration somewhere else would look identical in the patch.

CI is green on both legs, run 39077494242: test pass 3m44s, test-windows pass 4m18s —
the legs that also carry the guards a local run cannot reproduce.

What this vote does not say. It says nothing about the release being published: merging this
lands 0.3.18 in the tree and publishes nothing, and the running daemon keeps executing the
installed 0.3.17 until v0.3.18 is tagged and every platform builds. Stage 2 is a separate
reading, and green here is not green there.