Mark scheduled runs with nothing to build as cancelled instead of successful

[bjorkert]

Problem

The scheduled weekly run checks for new commits and only builds when something changed (or when the monthly forced build is due). When there is nothing to build, the build jobs are skipped and the run still completes with a green check — indistinguishable at a glance from a successful build. Users who rely on the green status can believe they have a fresh build even when their last real build attempt failed.

Change

A new cancel_when_no_build job in build_LoopFollow.yml fires only on scheduled runs where the build gate is false (no new commits and no monthly build due) and cancels its own run, so it shows as cancelled (grey) instead of successful.

Status semantics after this change:

• green — a new build was made and uploaded to TestFlight
• cancelled (grey) — the repository was already up to date, nothing was built
• red — a build was attempted and failed

Details:

• Manual (workflow_dispatch) runs always build and are unaffected.
• The job condition is the exact negation of the check_certs/build gate restricted to schedule events, so it can never fire alongside a build.
• Cancellation uses the run's own GITHUB_TOKEN with job-level actions: write — no new secrets and no third-party actions. The trailing sleep keeps the job alive until the cancellation lands, so the run cannot complete as successful first.
• Forks with SCHEDULED_SYNC/SCHEDULED_BUILD set to false also see cancelled instead of green on scheduled runs, consistent with green meaning "built".
• With GitHub's default "Only notify for failed workflows" notification setting, cancelled runs do not generate notification emails.

fastlane/testflight.md is updated to describe the new cancelled status, and its stale schedule description is corrected (checks run on Sundays with the forced monthly build on the second Sunday; the text still said Wednesdays / first of the month).