docs(mobile): describe automated candidate release handoff

.github/workflows/auto-tag-on-release-pr-merge.yml

@@ -12,18 +12,16 @@ name: Auto-tag on Release PR Merge
 #                       → tag chart-v<v>  → helm-chart.yml (helm chart)
 #
 # Mobile candidate tags do not come from merged PRs. Operators create immutable
-# mobile-v<v>-rc.N tags directly from remote main with scripts/mobile-release.sh,
-# then hand the exact tag to buzz-releases.
+# mobile-v<v>-rc.N tags directly from remote main with scripts/mobile-release.sh.
+# Publishing a candidate automatically triggers the private buzz-releases build
+# with the exact tag supplied as mobile_ref. The Buildkite input remains only as
+# a fallback for manually started builds; App Store Connect and Play Console own
+# the decisions to submit or publish each uploaded candidate.
 #
 # Release tags are created with a short-lived token from the dedicated
 # buzz-release-bot GitHub App. GitHub attributes the ref creation to that
 # App, so the consumer's `on.push.tags` trigger runs normally. The workflow's
 # default GITHUB_TOKEN remains read-only and is never used to create a tag.
-#
-# Mobile is manual-only by infosec necessity: OSS `block/buzz` CI must
-# not trigger CI in the private `buzz-releases` repo. A human feeds the exact
-# mobile candidate tag to the private Buildkite pipeline, which builds and
-# ships mobile.
 
 on:
   pull_request:

RELEASING.md

@@ -11,8 +11,9 @@ Mobile uses immutable release-candidate tags cut directly from remote `main`:
 
 The lanes version independently. Desktop reads its manifests, relay reads its
 crate manifest, and mobile derives both source and marketing version from the
-exact candidate tag. The mobile handoff to the private `buzz-releases` pipeline
-remains manual because OSS CI cannot trigger private CI.
+exact candidate tag. Publishing a candidate automatically triggers the private
+`buzz-releases` pipeline with that tag supplied as `mobile_ref`; the Buildkite
+input remains only as a fallback for manually started builds.
 
 ## Quick Start
 
@@ -72,14 +73,16 @@ Every push to `main` continues to publish the rolling relay `:main` and
    `mobile-vX.Y.Z-rc.N` tag there through the dedicated `buzz-release-bot`
    GitHub App. It never uses the operator's checked-out commit and never moves
    an existing candidate.
-2. **Build the exact tag.** Enter the candidate tag as `mobile_ref` in the
-   private Buzz mobile Buildkite pipeline. OSS CI deliberately cannot trigger
-   that private pipeline. The tag supplies both source commit and release
+2. **Build the exact tag.** Publishing the candidate automatically triggers the
+   private Buzz mobile Buildkite pipeline with the exact tag supplied as
+   `mobile_ref`. The pipeline's input step remains only as a fallback for
+   manually started builds. The tag supplies both source commit and release
    version. Flutter receives clean marketing version `X.Y.Z`; Buildkite's
    monotonically increasing build number supplies the platform build number.
-3. **Promote tested artifacts.** Promote the already-built signed artifact for
-   each platform through its store workflow. Record the exact tag with the
-   build or rollout record. No source ref is changed and no final build is cut.
+3. **Promote tested artifacts.** Every candidate build uploads to TestFlight and
+   Google Play. Decide what to submit or publish in App Store Connect and Play
+   Console, then record the exact tag with the build or rollout record. No source
+   ref is changed and no final build is cut.
 
 The iOS and Android artifacts for one marketing version may come from different
 RC tags. For example, iOS can ship `mobile-v0.5.0-rc.2` while Android ships