emrg: release v0.3.23 - the batching default and the batch label reach users #2417

Release v0.3.23.

What is being released

Seven commits sit on master past the v0.3.22 tag commit (1a060c2c):

The first is the one this release exists for. The round-cost rule in
emrg/server/prompts/system.j2 used to make several calls in one round a claim a caller had to
justify ("when no call's arguments depend on another's answer"), and the measured result was that it
almost never happened: over 157 sessions' history to 2026-10-20, 133,300 rounds contained 12,428
rounds (9.3%) holding two or more calls, and 92.5% of the lone ones named no awaited answer. The
rule now states the default in the other direction — issue every call you can already specify — with
the single-round exception kept, and the same direction in emrg/server/evolution_prompt.md, so both
carriers agree. A host feels this as fewer, fuller rounds on the same work.

The second is what makes the first legible: a round whose calls travelled together is labelled as
such in the TUI's tool cards and in the GUI transcript, so a host can see batching happen rather
than infer it.

Baseline, measured before the bump

• v0.3.22 is Latest — isDraft=false, isPrerelease=false, 11 assets including two .zsync
  files and EMRG-0.3.22-macos-arm64.pkg, which is what shows the last notarization succeeded
  (scripts/check-release-published.py v0.3.22 → OK).
• master is edf87973, seven commits past the tag commit 1a060c2c.
• Master's tip CI run 39421141051 is completed/success on both legs: test 2m22s,
  test-windows 5m10s.
• python3 scripts/bump-version.py --check → all 8 version sources agree on 0.3.22.
• No v0.3.23 tag exists.
• The installed tree reads 0.3.22.
• One open PR (emrg: the release-chain prompt assertion is pinned to the step that runs it #2412) and one open issue (emrg: the release chain runs the agent-prompt assertion, and nothing pins that it does #2411); neither touches a version declaration, so neither
  gates this release.

What must be true when this is done

1. All 8 version sources read 0.3.23, set through scripts/bump-version.py — never by
   hand-editing the scattered declarations.
2. Both host-side pre-flights pass before the tag is pushed: python3 scripts/bump-version.py --check and python3 scripts/check-release-tag.py v0.3.23. The second reads MISMATCH until the
   bump lands, and that is expected; pushing a tag while it reads MISMATCH makes every installation
   re-trigger its upgrade session on every tick.
3. The tag is the only trigger of build-release.yml. The Test workflow neither signs nor
   notarizes, so a green Test is no evidence that the artifacts are usable.
4. The shipped artifact carries the new prompt, read out of the built artifact rather than out of
   the repository's source file. app.asar packs only the Electron files, so system.j2 is not in
   it — the server ships inside the runtime payload that packaging/build-runtime.sh builds. This
   release is also the first to run the assertion that reads it, since the step landed after the
   v0.3.22 tag was cut.
5. scripts/check-release-published.py v0.3.23 verifies from the release itself: the
   four-platform matrix green, isDraft=false, isPrerelease=false, 11 assets of which 2 are
   .zsync, and macos-arm64.pkg present (the notarization signal).
6. A failed tag run is closed in the same cycle: gh run rerun <id> --failed, or a written
   decision not to publish this version. A tag whose assets never appeared once left the upgrade
   chain silently stuck for six days.

What this must not do

• It must not change the content of system.j2. That file is byte-identical to its design
  source on master; the release pull request carries the version number and nothing else.
• It must not carry the open PR emrg: the release-chain prompt assertion is pinned to the step that runs it #2412. A release built from a tree that also lands unrelated
  work cannot be described by the tag alone.