Support a public (unbranded) build flavor alongside VIPR

Summary

Today the app is built with VVG/VIPR branding applied by the branding:vipr step (scripts/apply_branding.sh vipr, sourcing branding/vipr/). We'd eventually like to also produce a public build — a plain APK without the VIPR logo/name/splash — so OpenBoxes can distribute a generic build that isn't tied to a single customer.

Background / how branding works today

• yarn branding:vipr → scripts/apply_branding.sh vipr copies launcher icons, splash, and in-app logo from branding/vipr/, and rewrites app_name in android/app/src/main/res/values/strings.xml from branding/vipr/settings.json ("app_name": "VIPR").
• In CI, the bundle::branding step runs before the release assemble in the android-only / UAT workflows (.bitrise/bitrise.yml).
• So "flavor" is currently a build-time asset/name swap, not a Gradle product flavor.

Proposed approach (to refine)

• Add a public/default branding target (e.g. branding/default/ + branding:default script, or a no-op/neutral branding) that applies OpenBoxes-generic assets and name.
• Add a dedicated android-public workflow in .bitrise/bitrise.yml that reuses the shared setup/release bundles but applies the public branding instead of branding:vipr (and likely a distinct app id / variant so branded and public builds can coexist on a device and in stores).
• Reuse the per-app Appetize routing pattern added in #430: the public build deploys to its own Appetize app via its own APPETIZE_*_PUBLIC_KEY, so flavors never collide.

Open questions / decisions

• Package name / application id for the public flavor (needed for store listings and side-by-side installs).
• Signing keys for the public build (separate keystore?).
• What "public branding" is (neutral OpenBoxes logo/name/splash assets).
• Distribution target (Play Store listing? internal only?).

Context

Split out of the OBLS-837 work (#430), which added the discrete-picking feature plus PR → Appetize preview CI plumbing. This is intentionally deferred and has product decisions attached, so it deserves its own ticket.

Start by reading scripts/apply_branding.sh, branding/vipr/, the package scripts, and the bundle::branding steps in .bitrise/bitrise.yml. Review the Appetize routing pattern from #430 and resolve the package ID, signing, assets, and distribution decisions. Done means the public branding target and android-public workflow are defined and can coexist with the VIPR build.