Fail on a malformed signing secret at the step that reads it

The first run with secrets present died on `base64: invalid input`. The secret
was there; it had a carriage return on the end, because piping a value into
`gh secret set` from PowerShell appends CRLF and GNU base64 treats a lone CR as
invalid. Nothing in that message points at the shell that set the secret.

Whitespace is now stripped before decoding, and the keystore is opened with
keytool right there. The password secrets carry the same CRLF hazard, and a
trailing byte on the password would otherwise have surfaced much later as a
signing failure blaming the keystore rather than the value.

Author: breslee1707

.github/workflows/android-build.yml

@@ -79,13 +79,23 @@ jobs:
         id: keystore
         env:
           KEYSTORE_BASE64: ${{ secrets.ANDROID_KEYSTORE_BASE64 }}
+          KEYSTORE_PASSWORD: ${{ secrets.ANDROID_KEYSTORE_PASSWORD }}
         run: |
           if [ -z "$KEYSTORE_BASE64" ]; then
             echo "No ANDROID_KEYSTORE_BASE64 secret; the release APK will be unsigned."
             echo "signed=false" >> "$GITHUB_OUTPUT"
             exit 0
           fi
-          echo "$KEYSTORE_BASE64" | base64 -d > "$RUNNER_TEMP/release.jks"
+          # Strip whitespace before decoding. GNU base64 rejects a lone CR as
+          # invalid input, and a secret set from a Windows shell or pasted into
+          # the web UI picks one up easily — the failure message says nothing
+          # about where the stray byte came from.
+          printf '%s' "$KEYSTORE_BASE64" | tr -d '[:space:]' | base64 -d > "$RUNNER_TEMP/release.jks"
+          if ! keytool -list -keystore "$RUNNER_TEMP/release.jks" \
+                 -storepass "$KEYSTORE_PASSWORD" >/dev/null 2>&1; then
+            echo "The keystore decoded but will not open. Check ANDROID_KEYSTORE_PASSWORD." >&2
+            exit 1
+          fi
           echo "signed=true" >> "$GITHUB_OUTPUT"
 
       - name: Build the release APK

docs/android-release.md

@@ -70,6 +70,24 @@ keyPassword=…
 | `ANDROID_KEY_ALIAS` | `vitranslate` |
 | `ANDROID_KEY_PASSWORD` | the key password |
 
+Set them with `gh secret set NAME --body "<value>"`, not by piping. A pipe from
+PowerShell appends CRLF, and a password secret with a trailing carriage return
+fails later with a signing error that names the wrong cause. The workflow now
+strips whitespace from the base64 and opens the keystore with `keytool` before
+building, so a bad secret fails at the step that set it.
+
+From PowerShell:
+
+```powershell
+$d = "C:\path\to\signing"
+$pw = Get-Content "$d\password.txt" -Raw
+$b64 = [Convert]::ToBase64String([IO.File]::ReadAllBytes("$d\vitranslate-release.jks"))
+gh secret set ANDROID_KEYSTORE_BASE64 --body $b64
+gh secret set ANDROID_KEYSTORE_PASSWORD --body $pw
+gh secret set ANDROID_KEY_ALIAS --body "vitranslate"
+gh secret set ANDROID_KEY_PASSWORD --body $pw
+```
+
 Without `ANDROID_KEYSTORE_BASE64` the workflow still builds, but the artifact
 is named `PDFTranslate-android-<version>-unsigned.apk` and the publish job
 refuses to release it. An unsigned APK will not install on a device; use the