Nothing keeps the checksummed and published asset sets in sync

Two definitions of "the release assets" exist and nothing keeps them in sync:

- `checksums.sh` hashes **every file** in `dist/`
- the release publishes a hand-maintained list of **six globs** in `auto-release.yml`

Drift is damaging in both directions, and both were reproduced:

- **A release glob matching nothing** publishes a short release with a `SHA256SUMS` that vouches for the shortfall. `fail_on_unmatched_files: true` (added in #44) now catches this specific case.
- **A file in `dist/` that no glob publishes** gets a manifest line for something nobody can download. `--ignore-missing` (also #44) means a user no longer sees a hard failure, but the manifest still claims a file the release does not offer.

Neither guard asserts the set is *right* — only that it is non-empty and that the globs matched something.

There is also a concrete trigger already in the tree. `build/linux.sh` derives the asset name from `uname -m`:

```bash
case "$(uname -m)" in
x86_64 | amd64) TARGET_ARCH="x64" ;;
aarch64 | arm64) TARGET_ARCH="arm64" ;;
OUT_FILE="$DIST_DIR/${APP_NAME}_${VERSION_NAME}_linux_${TARGET_ARCH}"
```

while both consumers hardcode `x64` — the upload path and the release glob. Linux is the only platform with this asymmetry: Android, macOS and iOS are arch-agnostic on both sides, and Windows is hardcoded on both. Moving that job to an arm64 runner would keep every step green while the Linux binary silently vanished from the release.

Note `if-no-files-found: error` does not help: `upload-artifact` globs the whole multi-line `path:` into one list and fails only when the combined list is empty. A job producing four APKs and no Linux binary uploads successfully.

- [ ] Assert the expected asset set in the publish job before writing the manifest, failing the release when a pattern is unmatched
- [ ] Make `build/linux.sh` and its consumers agree about the arch, either by loosening the glob to `_linux_*` or by having the script assert its computed arch