test: add Flutter remote push release check (MBL-2302)

[Shahroz16]

Summary

• add a trusted Flutter FCM delivery and opened-attribution release check
• identify a fresh profile, wait for iOS device registration, trigger the Mobile: Flutter send_push automation, and require backend delivery
• create a disposable iPhone 17 Pro simulator so stale notifications cannot affect SpringBoard grouping
• locate the Flutter notification through accessibility, reveal its system Open action, and require opened for the exact delivered message
• keep credentials and raw artifacts out of git

When it runs

Apply the run-remote-push-e2e label to a trusted, same-repository pull request to run the check once for its current head. It does not run for ordinary pull-request updates or on a schedule. Deterministic client routing remains covered by #400 without backend credentials.

Validation

• Bash syntax, ShellCheck, actionlint, Maestro YAML parsing, and diff checks pass on the current head
• the label starts only the dedicated Xcode 27 remote-push workflow
• the coordinate-free SpringBoard interaction was proven on a terminated sample using a disposable iPhone 17 Pro simulator
• the current-head credentialed run is waiting on the correct Mobile: Flutter App API credential; the existing local credential was rejected because it belongs to a different workspace

[github-actions]

Sample app builds 📱

Below you will find the list of the latest versions of the sample apps. It's recommended to always download the latest builds of the sample apps to accurately test the pull request.

---

• flutter_sample_spm: 401.54.0 (29797565)

[mrehan27]

Approving the design. On a credentialed workflow the parts that matter are right: pull_request rather than pull_request_target plus the same-repo if: guard means forks never receive secrets, and the artifact export at run_remote_push.sh:246-248 sits behind redaction and --check under set -e, so unredacted evidence can't reach the upload step. Run 33107750971 exercised that path end to end. Harness pinned by SHA and verified with rev-parse, Maestro pinned with a checksum, disposable simulator per run.

Still red on this head, though the failure has moved: the campaign preflight now passes and it fails at the first backend assertion (device_change / devices.0.platform within 45s). Worth confirming that's environment timing rather than the assertion itself before this lands.

[mrehan27]

P2 — every run identifies a new profile in the production Mobile: Flutter workspace and nothing removes it; there's no delete or suppression call anywhere in the script. Each run also triggers a real campaign send against that profile.

Label-gated so the rate is low, but profiles accumulate without bound and campaign 18's metrics collect synthetic sends. Worth deleting the profile in cleanup, or documenting a retention plan if these are deliberately kept.

[mrehan27]

P2 — campaign identity is hardcoded three ways: id 18 in the URL at :51, plus both name and event_name required to equal send_push. No override.

The validation itself is worth keeping — it fired correctly and caught a real mismatch on run 33105862946. The coupling is the problem: any of the three drifting yields one message that reads as a credential fault, and there's no way to point the check at a non-production workspace. Making the id and expected name configurable addresses both.