Add fork-safe Android release verification and device acceptance

[sacgsxr]

Summary

• make the GitHub release/update repository configurable with GITHUB_RELEASES_REPO while preserving the upstream default
• verify staged GitHub APK package, version, versionCode, SHA-256, and signing certificate in the release workflow
• add deterministic tests for the release verifier and expanded server URL/Tailscale endpoint coverage
• document the phone/tablet acceptance checklist and explicit human approval gate

Verification

• python3 -m pytest tools/tests/test_verify_release_apk.py -q — 12 passed
• python3 -m py_compile tools/verify_release_apk.py tools/tests/test_verify_release_apk.py — passed
• workflow YAML parse and GitHub Actions interpolation assertion — passed
• ./gradlew :app:testDebugUnitTest --no-daemon — 159 tests, 0 failures/errors/skips
• ./gradlew :app:assembleDebug --no-daemon — passed
• git diff --check — passed

Boundaries

• no tag or GitHub Release created
• no signing secrets read or changed
• real signed-APK verification remains gated on the release workflow
• phone/tablet installation remains a manual acceptance step

[nesquena-hermes]

Reviewed at exact head fa9f7d94c8c9aa1623ae0cdaa9543b97aa1fabe6 (source read + CI job inspection; no local build). Source-clean and ready to merge.

What holds up

• GITHUB_RELEASES_REPO override in app/build.gradle.kts is non-breaking: it falls back to hermes-webui/hermes-android and only accepts a candidate that is non-empty and contains /, so a malformed env var or Gradle property degrades to the upstream default rather than baking a broken .../releases/latest URL into BuildConfig. Local and upstream builds are byte-unchanged.
• verify_release_apk.py is secrets-safe by construction — it prints only the APK SHA-256 and the signing-cert SHA-256 digest, never keystore paths, aliases, or passwords, which matches the names-only discipline documented in RELEASE.md. run_tool fails closed on a missing tool or non-zero exit, and a missing cert digest is a hard return 1.
• The CI wiring fails closed correctly: the expected_version_code one-liner exits non-zero on a non-semver version_name, and under the runner's default set -e that aborts the release-verification step rather than passing --expected-version-code "" through. Verifier stdout is teed to $GITHUB_STEP_SUMMARY on both the pass and fail paths.
• Test coverage is real, not decorative: test_verify_release_apk.py drives package/versionName/versionCode mismatch exit codes and the cert-digest regex (uppercase, short, non-hex rejection); the Kotlin additions cover CGNAT range boundaries (100.64.0.1 / 100.127.255.255 in, 100.63.0.1 / 100.128.0.1 out) and blank/host-less/invalid-octet URL rejection.
• All 11 checks green including API-35 and API-36 instrumentation and the Debug APK build.

Non-blocking notes (for the manual-acceptance path, not the CI path)

• The verifier requires both aapt/aapt2 and apksigner on PATH. CI has the Android SDK so this is fine; the RELEASE.md PowerShell example assumes an operator dev box also has build-tools on PATH — worth a one-line prerequisite mention there if a non-CI operator ever runs it by hand.
• APK identity verification is scoped to the github APK only (not the Play AAB), which matches the PR's stated scope; flagging only so it isn't mistaken for full-artifact coverage.

Scope-wise this is operator/deployment hardening of the release pipeline (configurable fork releases + signed-artifact identity verification + a device-acceptance checklist behind an explicit human approval gate), which is squarely in-scope. Nothing here needs a change to merge.