[PM-42956] Release APK not reproducible: CI run/branch info baked into classes.dex (2026.8.0)

## Reproducibility report — Android 2026.8.0 (fdroid APK)

An independent rebuild of the `v2026.8.0-bwpm` tag (commit 8be53c1) with a read:packages token resolving `com.bitwarden:sdk-android:3.0.0-8157-eb825d59` produced an APK that matches the official release APK in **659 of 661 ZIP entries** (identical: `resources.arsc`, `AndroidManifest.xml`, `version-control-info.textproto`, all resources and native libs).

Two entries differ:

1. **`classes.dex`** — the only string-level differences are CI provenance baked into the binary:
- ` build source: bitwarden/android/actions/runs/31214376447/attempts/1`
- ` commit: bitwarden/android/release/2026.8-rc60@8be53c1ae519ab417b64b0d2154f9815adf7c44a`

The variable-length CI-info string shifts subsequent offsets, scattering ~700KB of bytes with zero semantic difference. Providing `ci.properties` (or documenting `ci.info`) for release builds, or making the CI-info injection length-stable, would make this APK byte-for-byte reproducible by third parties.

2. **`assets/dexopt/baseline.prof`** — likely downstream of the same offset shifts.

Note: `appVersionName`/`appVersionCode` in `gradle/libs.versions.toml` are not bumped on the tag, so rebuilders must pin `2026.8.0`/`21819` manually; tagging with the values already set would remove another manual step.

Verdict: **near-reproducible** — only CI provenance metadata blocks byte-identity. Attestation (kind 30301) published; happy to share build details.

Start with the v2026.8.0-bwpm tag and trace how CI provenance is injected into classes.dex, using the reported ci.properties or ci.info inputs. Check gradle/libs.versions.toml for the release version values, then rebuild and compare classes.dex and assets/dexopt/baseline.prof; done means the APK matches the official 661 entries byte-for-byte without manual CI metadata.

Written by the indexing model from the issue text.