rollout-guardlisted

# rollout-guard A backend deploy is reversible in minutes: roll back the container, the old code is live again. A mobile app release is not. Once a build is approved and a user installs it, there is no `rollback` — halting a staged rollout stops *new* installs, but everyone who already updated keeps the build you're trying to take back. And getting a fix in front of anyone requires clearing app-store review first, a queue you don't control and can't reliably time. Teams that treat a mobile release like a backend deploy — assume "we'll just hotfix it" or "we'll pause the rollout" — find out the difference during an incident, not before. Two mechanisms make this genuinely different from `skew-check`'s mixed-version deploy window or `ship-it`'s release checklist, and both need to be reasoned about explicitly: 1. **The review clock is not your incident clock.** Apple's standard review typically clears in under 48 hours but has no guaranteed SLA; expedited review exists for genuinely critical fixes but is a discretionary favor Apple can throttle if a team leans on it routinely, not a service you can schedule around. Google Play review is usually faster but not instant either. Anything that must respond to an incident in minutes — kill a broken feature, disable a broken endpoint, change a rate limit — has to already be reachable from a server-side switch the *current* build ships with. If the plan for "what do we do when this breaks in prod" is "we'll push a fix," that plan has