fix(mobile): declare the release_branch input on EAS development

[omegent-app]

The first fork/dev sync merge (ae4719b1c, #345) passed every required check and still ended
as a failed run:

Check ✅  Test ✅  Mobile Native Static Analysis ✅  Release Smoke ✅  Classify Deployment Scope ✅
Dispatch Mobile Releases ❌  HTTP 422: Unexpected inputs provided: ["release_branch"]

Because the deploy poller only promotes a SHA whose fork-ci run concluded success, that one
failure blocked server, Discord, desktop and VS Code deployment of ae4719b1c entirely. The guest is
still sitting on 21badd04e.

Cause

#344 added the release_branch input declaration
to mobile-eas-production.yml, but for mobile-eas-development.yml it only rewrote the usages —
leaving the file referencing inputs.release_branch without declaring it. Production dispatch
succeeded; development was rejected.

The validation in that PR printed the default for production and nothing for development. That was
the evidence, and it was read past.

Change

Declare the input with the same fork/integration default, so a manual dispatch that omits it
behaves exactly as before.

Validation

Rather than eyeball it again, all three workflows are now checked for inputs.* references with no
matching declaration:

fork-ci.yml                | declared: checkout_ref                                    | undeclared: none
mobile-eas-production.yml  | declared: mode,platform,message,runtime_version,sha,release_branch | undeclared: none
mobile-eas-development.yml | declared: platform,runtime_version,sha,release_branch      | undeclared: none

Separate design question, not fixed here

Should a release-dispatch failure invalidate a validation verdict? Dispatch Mobile Releases
performs a release action; the other five jobs validate the SHA. Mixing them in one run means any
dispatch hiccup — a 422, a transient API error — marks the SHA unapprovable and stalls the whole
fleet, which contradicts the handover doc's own rule that per-target release status is recorded
independently and that one target's failure must not hold back the others.

Two options, both one-liners:

• continue-on-error: true on dispatch_mobile_releases — run concludes success, the failed job
  stays visible, mobile status is tracked by the EAS workflows anyway.
• Move the dispatch into its own push-triggered workflow so fork-ci's conclusion means "this SHA
  is valid" and nothing else.

I did not apply either, because weakening the deploy-approval signal is a policy call. Say which you
want and I'll do it.

Co-authored by @patroza

opened by Patrick Roza in chat thread Discord · Discord · T3