Sign the Android build with a real key, and let package.sh use it too

The release keystore now exists and its four secrets are loaded into
Gitea, so CI produces an APK a device can update in place. Until now
every build, CI and local alike, was signed with a throwaway debug key
-- CI's fresh per run, the local one exactly as durable as the cache
directory it lived in -- and the night that cache was cleared, no build
anywhere could install over the tablet's copy.

package.sh forwards KEYSTORE_PASS, KEY_PASS and KEY_ALIAS into the
container and copies the keystore under the mounted target directory
for the build, so a local release-signed build is one environment line.
The doc records where the local copy of the key lives.

docs/android-signing.md

@@ -35,6 +35,22 @@ beyond telling everybody to uninstall and reinstall.
 line, which keeps them out of shell history. Back the `.jks` up somewhere that
 is not this repository and not the machine that builds it.
 
+**The key exists, since 2026-09-11.** It was made as above, with a random
+password, and the four secrets are loaded. The local copy is at
+`~/.config/darkroom/signing/` on the development desktop — `darkroom-release.jks`
+beside `storepass` and `keypass`, all mode 600 in a mode 700 directory. That
+copy is what `package.sh` can sign with locally:
+
+    D=~/.config/darkroom/signing
+    KEYSTORE="$D/darkroom-release.jks" KEYSTORE_PASS="$(cat "$D/storepass")" \
+        KEY_ALIAS=darkroom ./docker/android/package.sh --install
+
+Before it existed, every build — CI and local alike — was signed with a
+throwaway debug key, and a debug key is exactly as durable as the cache
+directory it lives in: the local one was regenerated the night the cache was
+cleared, at which point no build anywhere could install over the device's copy.
+Any device that received a build from before this date has to uninstall once.
+
 ## Loading the secrets
 
     base64 -w0 darkroom-release.jks > /tmp/ks.b64