emrg: the release chain asserts a product's version but never the prompt it carries #2400

The release chain asks a product one question about itself — the version it declares — in scripts/check-release-artifact-version.py, run by build-release.yml's Assert the artifacts declare the version the tag names step. It asks nothing about what the product carries. A build from an older tree that declares the right version therefore passes every check and still hands the host the previous agent prompt while the release names the new one: the same defect class as a stale version.txt, one layer up.

Observed

Measured on this host on 2026-10-20.

• The published EMRG-0.3.21-linux-x86_64.tar.gz carries exactly one runtime/source/emrg/server/prompts/system.j2: 24,558 characters, the text from before the system-prompt rewrite — ## Tool Usage, no ## Hard limits.
• The tree this checkout is on carries 7,360 characters with ## Hard limits.
• Nothing would have reported the difference. tests/test_version_sync.py compares the eight source declarations, check-release-tag.py compares the tag with the tagged tree, and check-release-published.py reads the release's metadata — draft, prerelease, asset names — without opening one asset.
• The prompt is not in app.asar and a reading pointed there finds nothing: emrg/gui/package.json's build.files packs the Electron files only (main.js, preload.js, renderer/** and siblings). The server ships inside the runtime payload packaging/build-runtime.sh builds, so the reading has to come from that payload or an installer.

Expected

A release whose product carries a different prompt than the tree the tag names is refused before the release is created. The refusal names the product, both character counts, and the first line where the two texts part — enough for a reader to see whether this is a stale build or a real edit.

What this must satisfy

1. A tool that reads the shipped copy out of a product and compares it with this tree's own copy. Subjects: a runtime .tar.gz/.tgz, or an expanded payload directory (which is also the shape a .pkg payload and an AppImage's squashfs-root take). Exit 0 identical / 1 a product carries a different text / 2 nothing could be read — never 0 for a product it did not open, and never 0 for a product that does not carry the file at all.
2. build-release.yml's release job runs it after the version assertion and before the release is created, over the artifacts that job has downloaded. It must be wired into the chain, not only documented: a tool nobody runs answers nothing.
3. The tool takes part in the family contracts the other release tools follow — an unexpected failure answers 2 rather than a verdict code, and the report names the tree it read before it prints any verdict.
4. A host-side command in DEVELOPMENT.md, so a release can be checked before the tag is pushed.
5. Tests that build a passing product, a differing one, and an unreadable one, and pin each exit code.

What this must not do

• It must not report an unreadable product as a passing one, and it must not collapse "could not measure" into "identical".
• It must not widen the version checker to cover this: that tool's docstring rules it out, and two subjects in one exit code are two questions no caller can tell apart.

Part of the same v0.3.22 requirement as #2398 — that issue covers the bump and the release itself; this one covers the reading the release has to be able to make. see #2398