[Feature]: Publish a rolling "android-latest" release for a stable APK download URL

### Problem or use case

Orca Android is distributed as an APK attached to GitHub Releases (no Play Store), so the download pointer users follow is the **README link**. That link is bumped by a **manual PR** each release (e.g. #7380, #7262), so it lags the actual newest `mobile-android-v*` release: as of today the README points at `0.0.22` while `mobile-android-v0.0.24` is the newest published APK, and one README-bump PR (#6291) has sat un-merged since `0.0.16`.

Two concrete consequences:

1. **Users following the README download a stale APK** — there is a real gap between "newest release cut by CI" and "what the README points at," gated only on a human running the link-bump chore.
2. **There is no stable, unchanging URL for "the latest Android APK."** Every release URL is version-specific (`…/download/mobile-android-v0.0.24/app-release.apk`), so the README, docs, and any external tooling (install scripts, an Obtainium version-regex) must be re-pointed on every single release.

The in-app update check in #7328 is a good fix for the *in-app* discovery path, but it doesn't provide a stable external URL, doesn't fix the README lag, and doesn't help a user who isn't yet on a build new enough to have the updater.

### Proposed solution

Publish a **rolling `android-latest` GitHub Release**: on each `mobile-android-v*` publish, have CI attach the freshly-built APK to a single, permanent `android-latest` release, replacing the previous asset (e.g. `softprops/action-gh-release` clobbering the asset by name, which upserts and avoids the brief 404 / 422-name-collision window of a delete-then-reupload).

Result: a permanent URL that always serves the newest APK —

```
https://github.com/stablyai/orca/releases/download/android-latest/app-release.apk
```

- The README links this **once** and never needs bumping again — the manual-PR lag disappears structurally.
- Keep the existing immutable `mobile-android-v0.0.X` tags for per-version history/changelogs; `android-latest` is purely a "current build" convenience pointer.
- Mark the `android-latest` release `prerelease: true` so it never contends for the repo-wide `releases/latest` slot (desktop keeps that; there is only one "latest" per repo).

### Alternatives or additional context

**Prior art:** neovim ships fixed rolling `stable` and `nightly` tags exactly this way — permanent download URLs independent of GitHub's single repo-wide "Latest" badge. A rolling-latest tag is a common complement to per-version tags for projects distributing installable artifacts via GitHub Releases.

**Alternatives considered:**
- *A per-Android `latest-version.json` manifest* (mirroring the iOS one): redundant — Android already live-enumerates the Releases API in #7328, and a manifest is machine-only (it neither helps the README/human download path nor yields a clickable APK URL).
- *Automating the README-bump inside the release workflow*: works, but still churns the README on every release and still yields no stable URL; the rolling tag subsumes it.

Purely additive — doesn't change release cadence, the `mobile-android-v*` scheme, or the prerelease-flag policy. Complements #7327 / #7328 rather than replacing them.