v0.9.2

A release-infrastructure release: no functional change to polyrouter itself. It exists because
publishing a release had become unreliable, and because the fix deserved to be proven on a
version with nothing at stake.

Highlights

Release images are built on native runners per architecture. The linux/arm64 half of
every image used to be cross-built under QEMU emulation, which is a nondeterministic-failure
generator — and it broke two of the last three releases. On v0.9.1 it crashed with
qemu: uncaught target signal 4 (Illegal instruction) - core dumped 68 seconds into npm ci
and then wedged: the build never failed, it emitted progress heartbeats for another 88
minutes until the job timeout killed it. A retry on byte-identical inputs passed with zero
crashes.

That is how v0.9.1 shipped half a release — the -semantic variant published while the
baseline image did not, leaving latest serving 0.9.0 for about two hours.

Each architecture now builds on its own native runner, pushes an untagged digest, and a merge
job assembles the manifest list. Tagging happens once, at the end, so no architecture can
clobber another's latest, and -semantic is now ordered strictly after the baseline — the
v0.9.1 failure mode is structurally impossible rather than unlikely.

Measured, all caches cold: the arm64 leg that wedged for 88 minutes finishes in 1m45s,
and the entire release — both variants, four builds, two merges — takes 3m40s, against
20m42s on the best previous emulated run. The -semantic arm64 leg is now faster than its
amd64 sibling doing identical work.

The -semantic smoke test got stricter for free. It loads the baked model and runs a real
ORT inference on both arches before publishing. Under emulation the arm64 pass was validating
QEMU's softfloat; it now exercises ORT's actual arm64 kernel dispatch on real hardware.

Fixed

• org.opencontainers.image.licenses annotations reported the deprecated AGPL-3.0 while
  the matching label correctly said AGPL-3.0-only. A custom label does not propagate to
  annotations in docker/metadata-action; both now agree.

What did not change

The published contract is identical: same tags, same two platforms (linux/amd64 +
linux/arm64), same plain manifest list with no attestation entries, same labels and index
annotations. Image contents are unchanged from 0.9.1 apart from the licence annotation — no
application code was touched in this release.

Upgrade notes

Nothing to do. This changes how images are built, not what they contain.

docker compose pull && docker compose up -d

Pinning a digest instead of a tag? 0.9.2 is a fresh build, so its digest differs from
0.9.1 even though the application code is the same.