docs(release): a release request carries through to rollout

The upload execution policy stopped an agent at upload: App Review
submission and rollout each needed their own explicit authorization, so a
request to ship a release ended with an artifact sitting in App Store
Connect and a question back to the user. That contradicted the harness
standard in documentation/standards/react-native.md, which has always
authorized the full pipeline, and it is the wrong default: every step from
here is recoverable. A submission can be cancelled while it waits for
review, a phased release paused, a staged rollout halted.

A release request now authorizes build, verification, upload, App Review
submission, and rollout for the platforms it names.

What still needs its own authorization is anything that is not part of
shipping the requested release: widening TestFlight distribution to new
groups, and re-uploading after an ambiguous upload result. The existing
automatic-TestFlight-distribution check before an iOS upload is unchanged.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/releasing.md

@@ -37,8 +37,9 @@ Output files are placed in the current directory by default.
 
 These scripts create signed artifacts only. They do not upload or submit them.
 An explicit request for a mobile release, upload, or store-submission workflow
-authorizes the requested store upload within its stated platform and destination
+authorizes the full pipeline within its stated platform and destination scope:
-scope. Building an artifact alone does not authorize an upload.
+upload, App Review submission, and rollout. Building an artifact alone does not
+authorize an upload.
 
 Before every production build, run the deterministic source gate:
 
@@ -89,11 +90,17 @@ inferring the effect from API data.
 Do not use `--latest` for a local release. Before upload, verify the artifact's
 package or bundle identifier, public version, build number, signature, and
 SHA-256 digest. After upload, read back the same identity and version from Google
-Play Console or App Store Connect. Public rollout, App Review submission, and
+Play Console or App Store Connect.
-additional TestFlight group distribution remain separate, explicitly authorized
+
-actions unless the original request expressly includes them. If an upload command
+A release request authorizes the whole pipeline for the platforms it names:
-returns an ambiguous result, inspect EAS and the store first; do not retry unless
+build, verification, upload, App Review submission, and rollout. Carry it
-the user explicitly authorizes another upload.
+through and report what happened rather than stopping at upload to re-confirm.
+Every one of those steps is recoverable: a submission can be cancelled, a
+phased release paused, a staged rollout halted. Two things still need their own
+authorization, because neither is part of shipping the release that was asked
+for: distributing to additional TestFlight groups, and re-uploading after an
+ambiguous result. If an upload returns an ambiguous result, inspect EAS and the
+store first; do not retry unless the user explicitly authorizes another upload.
 
 ### Source integrity
 
@@ -305,18 +312,18 @@ android/app/build/outputs/bundle/release/app-release.aab
 ### Step 5: Upload to Play Store
 
 Apply the upload execution policy above before opening or changing the release.
-Uploading the AAB and starting any rollout are separate actions unless the
+A release request covers the rollout, so carry it through to the track the
-original request expressly includes the rollout.
+request named.
 
 1. Go to [Google Play Console](https://play.google.com/console)
 2. Select **Sauci** app
 3. Go to **Internal testing**, unless the user authorized a different exact track
 4. **Create new release**
 5. Upload the `.aab` file
-6. Add release notes, save the release as a draft, and read it back
+6. Add release notes, then send the release and read it back
 
-Do not send the draft for review or start a rollout unless the original request
+Roll out to the track the request named. Halt the rollout if the read-back does
-expressly includes that action.
+not match what was uploaded.
 
 ### Verifying Keystore Fingerprint
 
@@ -364,8 +371,9 @@ verified automatic TestFlight distribution before uploading.
 
 ### Step 5: Submit in App Store Connect
 
-Submitting for App Review is not authorized by an upload request unless the
+A release request covers App Review submission, so carry it through. Submission
-original request expressly includes App Review submission.
+is recoverable: it can be cancelled while waiting for review, and a phased
+release can be paused after approval.
 
 1. Go to [App Store Connect](https://appstoreconnect.apple.com)
 2. Select **Sauci**