chore: support release reproducibility

[ovitrif]

Closes #953
Related: #1006
Replaces the release reproducibility portion of #959.

Description

This PR splits the reproducibility work out of #959:

• Adds the manual Reproducible Release workflow for mainnetRelease reproduction artifacts.
• Adds scripts/reproduce-release.sh to build/reuse the release AAB, recreate APK splits with pinned bundletool, extract arm64 native libraries, and write checksums.
• Fails early when the supplied release signing key is not RSA, because EC/ECDSA signatures are not byte-stable across signing runs.
• Documents the local and GitHub Actions reproduction flow in docs/reproducible-builds.md.
• Documents the remaining upstream native-library reproducibility work related to v2.2.0: Native libraries not reproducible (libbitkitcore.so, libdatastore_shared_counter.so, libjnidispatch.so, libpubky_app_specs) #953.

Preview

N/A

QA Notes

Manual Tests

• 1. Reproducible Release workflow → run manually with release environment secrets: artifacts upload and diffoscope comparison behave as expected (after merge).

Automated Checks

• bash -n scripts/reproduce-release.sh
• go run github.com/rhysd/actionlint/cmd/actionlint@latest .github/workflows/reproducible-release.yml
• git diff --check
• Signing-key verifier smoke: extracted the embedded Java verifier and confirmed a throwaway RSA keystore reports RSA, while a throwaway EC keystore reports EC.
• Comparison-input preservation smoke: confirmed an overlapping DIFFOSCOPE_COMPARE_DIR is copied to a temp dir before cleanup and remains available after the generated output directory is removed.

[piotr-iohk]

Given the release workflow concern @catch-21 raised, I think we should close this for now and rethink the reproducibility flow.

This workflow uses the production release environment and keystore secrets, so it has the same risk profile as an actual release workflow. Since the intended consumer is WalletScrutiny / external verification, I don't think we should add another manually dispatched workflow with signing material in bitkit-android.

Also, moving this exact workflow to a private bitkit-android-release repo may not solve the WalletScrutiny use case, because external verifiers need a public/auditable reproduction path.

[ovitrif]

Given the release workflow concern @catch-21 raised, I think we should close this for now and rethink the reproducibility flow.

This workflow uses the production release environment and keystore secrets, so it has the same risk profile as an actual release workflow. Since the intended consumer is WalletScrutiny / external verification, I don't think we should add another manually dispatched workflow with signing material in bitkit-android.

Also, moving this exact workflow to a private bitkit-android-release repo may not solve the WalletScrutiny use case, because external verifiers need a public/auditable reproduction path.

Agree 🤝