Publish a fixed-name APK so the latest build has a permanent link

GitHub's /releases/latest/download/<name> redirect needs a file name
that stays put, and the release asset is named after its version. Each
production release now carries the same build twice: the versioned copy,
and a plain ProLibertateGames.apk, which makes this link permanent:

  .../releases/latest/download/ProLibertateGames.apk

Only the production channel gets one. /releases/latest skips
prereleases, which is exactly what stops a production install being
handed a dev build, so there is no equivalent dev link to offer.

The updater now picks its asset by name rather than taking the first
.apk it sees. Both copies are byte-identical, so nothing would have
broken either way, but relying on upload order for which file gets
installed is not something to leave lying around.

README.md

@@ -111,6 +111,22 @@ Requires JDK 17 and the Android SDK (compileSdk 34).
   publishes it as a GitHub Release tagged `v1.0.<run-number>`. The in-app updater
   reads that tag, which is why the APK's `versionCode` is the same run number.
 
+### Installing without the app
+
+The newest production build is always at this link, which never changes:
+
+**https://github.com/adrianoftyriel/ProLibertateGames/releases/latest/download/ProLibertateGames.apk**
+
+Every release carries the same APK twice — once named for its version, and once
+as plain `ProLibertateGames.apk`, because GitHub's `/releases/latest/download/`
+redirect needs a file name that stays put. The in-app updater deliberately picks
+the versioned copy, so an installed build can always be traced back to its tag.
+
+There is no equivalent link for the dev channel: `/releases/latest` skips
+prereleases by design, and that is exactly what keeps a production install from
+being handed a dev build. Dev builds are reached through the in-app updater with
+the channel set to dev, or from the releases page.
+
 ### Update channels
 
 Both pipelines publish, to two separate channels: