Publish aarch64 Linux builds

[vstrelnikof]

release.yml publishes exactly three installers: x86_64 MSI, universal macOS DMG, x86_64 AppImage. An aarch64 Linux user (Raspberry Pi 5, Asahi, ARM laptops/servers) has nothing to download, and the in-app updater's platform key has nothing to offer them either — by design it refuses rather than guessing.

What's needed:

1. A release job producing an aarch64 AppImage — either GitHub's free arm64 runners for public repos (ubuntu-24.04-arm) building natively, or cross/zig-based cross-compilation. Native runner is probably less pain (the AppImage tooling and any native deps just work).
2. platform_key() in crates/poltertype-update/ learning the new target, and latest.json gaining the asset entry, so self-update works for those installs.
3. README platform table + the site's download section noting the new artifact (site copy follows the release, not the branch).

Constraint worth honouring: keep it to one additional artifact. Every extra installer is a support surface; armv7, ARM Windows etc. stay out of scope unless someone shows up with real hardware and real demand.

[vstrelnikof]

Done in PR #17.

The AppImage job is now a two-entry matrix, both native: ubuntu-latest
for x86_64, ubuntu-24.04-arm for aarch64 (free for public repos). Native
rather than cross-compiled because the binary links the system GTK/X11/Wayland
stack and is then packaged by a tool that is itself an AppImage —
cross-compiling both halves buys nothing but breakage.
build-appimage.sh takes ARCH, which drives the Rust triple, the linuxdeploy
asset and the output name alike, and refuses anything it has no linuxdeploy
build for.

platform_key() already produced linux-aarch64 — what it lacked was a
manifest entry to match, so latest.json gains one and the release uploads the
new artifact. The test that pins platform_key() to the published set grew the
key, so the workflow and the binary cannot drift apart without something going
red; that drift is a silent no-updates bug for the affected platform, which
is why it is a test and not a comment.

One extra artifact and no more, as the issue asked: every installer is a build
to keep green, a download to explain and a self-update path to get right, so
armv7 and ARM Windows stay out until someone turns up with the hardware.

README platform table and the release notes updated. The site copy follows the
release, not this branch — it gets the row when v0.6.4 is actually published.