ci: publish iOS and Android core-screen screenshots on mobile PRs

Follow-up from #4 and the mobile delivery plan.

Every mobile-facing pull request must receive one service-authored comment containing current iOS and Android screenshots of the core screens for human visual validation.

Acceptance criteria

• capture deterministic fictional-data states from release builds on a pinned iPhone simulator and Android emulator
• cover onboarding, empty family, profile form, populated family, profile detail, and monetization gate screens
• publish both platforms inline in one comment, labelled with OS/device and commit SHA
• update the existing comment in place on every relevant push instead of adding comment noise
• retain diagnostics separately and still update the comment when either platform fails
• never capture real credentials, document data, OTPs, share codes, or live GOV.UK pages
• make missing or stale captures visible as a required PR check
• document the chosen image hosting/service, retention policy, fork-PR permissions, and secret exposure model

The implementation should build on the Maestro native jobs introduced in #4. Evaluate a purpose-built visual review service before attempting to expose GitHub artifact internals as image URLs.

Start by reviewing the Maestro native jobs introduced in #4 and the mobile delivery plan. Evaluate a purpose-built visual review service, including image hosting, retention, fork permissions, and secret exposure. Done means relevant mobile PRs receive one updated comment with deterministic iOS and Android core-screen captures, diagnostics remain separate, and stale or missing captures fail a required check.