SPORE v0.4.0

• The release-bump workflow's first run failed on its last line. Three separate
  defects, all mine: GitHub Actions cannot open pull requests unless the repository
  enables it (off by default, and I did not check), a re-run would have died on the
  branch the failed run left behind, and the "is ## Unreleased empty" guard counted
  the section's own explanatory boilerplate as content — so it would have cut 0.4.0
  with a changelog consisting of the text describing what changelogs are for. The PR
  step is now best-effort with a printed link, the push is --force-with-lease, and
  the guard requires an actual - bullet.
• S-030 The tag-cutting step looked up v0.3.0 but the existing tag was
  V0.3.0; git tags are case-sensitive, so it missed it and published a second
  release for the same version. That is S-025's exact trap reproduced inside the fix
  for S-025. Now checks both cases. One accidental upside: the duplicate became
  "latest" and releases/latest/download/spore-android.apk returns 206 for the first
  time — a correct outcome from a broken mechanism, which is the most misleading
  state a release pipeline can be in.

Entries accumulate here as work merges. release.yml retitles this heading to the
new version when you bump, and refuses to release if it is empty — a release nobody
can read about is the failure this guards against.

Nothing yet.

---

⬇ spore-android.apk
— a permanent link that always serves the newest stable release.

This number versions the distribution, not the protocol. The SPORE v1
wire format and the crate's API shape are frozen and unaffected by it.

Before you rely on it: no radio bridge has been verified against real
hardware (every 🧪 in
BRIDGES.md),
and the Still open section of
SECURITY_FINDINGS.md lists
what is known and unfixed. Builds are debug-signed until a release keystore
is configured, so Android will warn about an unknown developer.
SHA-256 7d5beaaeae207012079687cfbd61f6f71560ebb0b6da075a68fcbb92fd12e40e