Turn on the fourteen iOS workflows that are re-homed but held on dispatch

[TarikGul]

All fifteen iOS workflows sit at the repository root after #728, #741 and #754,
but only ios-pr.yml triggers. The other fourteen are held on
workflow_dispatch with their real triggers commented out in place, so restoring
one is a readable diff rather than a rewrite.

They were held back because they need things this repository does not have yet.

Secrets

The pull request checks needed four, all now set. The rest need roughly nineteen
more, all present on the source repository:

area	secrets
App Store Connect	ASC_KEY_ID, ASC_ISSUER_ID, ASC_KEY_BASE64
Firebase	FIREBASE_APP_ID, CREDENTIAL_FILE_CONTENT, GOOGLE_SERVICE_INFO_RELEASE_BASE64, GOOGLE_SERVICE_INFO_SAFETY_BASE64
S3	SCW_ACCESS_KEY, SCW_SECRET_KEY
distribution links	TESTFLIGHT_DISTRIBUTION_LINK, TESTFLIGHT_SAFETY_DISTRIBUTION_LINK, WEB_PAGE_DISTRIBUTION_LINK
reporting	ALLURE_TOKEN, SENTRY_AUTH_TOKEN
notifications	NOTIFICATION_BOT_TOKEN, NOTIFICATION_BOT_URL, CI_MATRIX_ROOM_IDS

ASC_KEY_ID and ASC_ISSUER_ID are already set. Four names are referenced but
exist nowhere: FASTLANE_RW_PAT, MELD_BASIC_AUTH_TOKEN, SENTRY_DSN and
WEB_PAGE_SAFETY_DISTRIBUTION_LINK. Two of those are not build-blocking.

GOOGLE_SERVICE_INFO_SAFETY_BASE64 is a separate Firebase app for the .safety
bundle identifier, so it cannot be derived from the others.

Branch filters that name another repository's model

Several carry branches: [develop] or branches: [main] from the source
repository's branching model. develop does not exist here, so restoring those
verbatim gives filters that never match. Each needs a decision rather than a
restore.

A decision before any of it

Turning these on here means this repository starts distributing builds, cutting
release branches and pushing tags, while the source repository may still be
doing the same. Running both is worse than running neither. So the order matters:
the source repository stops, then these start. That is the same cutover #687 and
#726 describe.

Steps

• Decide which of the fourteen should run here at all, and which retire
• Provision the secrets for the ones that stay
• Replace the branch filters with this repository's model
• Restore triggers, one workflow at a time rather than in a batch
• Confirm the source repository has stopped running the equivalent

Depends on: #672 for the secrets, and the cutover in #687.

Cutover: Thursday 17 September

Everything below must be reversed on the day. Each is a deliberate hold, not an
oversight, and each is a small edit rather than a rewrite.

• Restore the pull_request triggers commented out in ios-pr's siblings:
  ios-firebase-debug-distribution, ios-release-branch-lifecycle,
  ios-release-distribution
• Restore the schedule triggers commented out in
  ios-collect-prs-summary, ios-nightly-prepare,
  ios-nightly-simulator-release, ios-update-signing-data
• Remove the six if: false guards added in ci(ios): hold every iOS workflow that can reach Apple until the cutover #787, from
  ios-safetynet-distribution, ios-testflight-distribution,
  ios-update-signing-data, ios-register-device, ios-release-prepare
  and ios-nightly-prepare, restoring the conditions preserved in the
  comments beside the TestFlight and register-device ones.
  ios-nightly-distribution and ios-release-distribution are not
  guarded and need no change
• Fix the stale dispatch filenames in Do not fix before cutover: the prepare workflows dispatch filenames that no longer exist #790, which must not be corrected
  before this point: they are what currently breaks the prepare chain
• Refresh the import against the frozen app repository, per Refresh the host imports before each host cuts over #726
• Confirm the app repository has stopped releasing before any of the above

The original trigger configuration is preserved in place as comments throughout,
so none of this needs reconstructing from memory.

What is currently held, and how

Two mechanisms, because two different constraints. Nothing else in the repository
records this, so it lives here.

workflow	mechanism	why	release when
ios-firebase-debug-distribution	pull_request commented out in on:	needs credentials	#672
ios-release-branch-lifecycle	pull_request commented out in on:	needs credentials	#672
ios-release-distribution	pull_request commented out in on:	needs credentials	#672
ios-collect-prs-summary	schedule commented out in on:	needs credentials	#672
ios-nightly-prepare	schedule commented out in on:	needs credentials	#672
ios-nightly-simulator-release	schedule commented out in on:	needs credentials	#672
ios-update-signing-data	schedule commented out in on:	needs credentials	#672
ios-safetynet-distribution	if: false on build_safetynet	uploads to the .safety record, nothing else stopped it	cutover
ios-testflight-distribution	if: false on distribute_testflight	uploads to the production record	cutover
ios-update-signing-data	if: false on update_signing_data	match with readonly: false over the production identifiers	cutover
ios-register-device	if: false on register_device	registers devices at App Store Connect	cutover
ios-release-prepare	if: false on prepare	drives the release distribution chain past the bot check	cutover
ios-nightly-prepare	if: false on prepare	drives the nightly distribution chain past the bot check	cutover

Not held, and deliberately so:

• ios-nightly-distribution and ios-release-distribution call
  ios-build-distribute.yml, which already fails a hand-started run with an
  explicit security error. Holding them too would replace a loud failure with a
  skipped job, and a skipped job reports the run as successful.
• ios-firebase-debug-distribution stays dispatchable. It is ad-hoc signed,
  distributes to a tester group, and never touches App Store Connect.

Each held trigger or condition is preserved verbatim in a comment beside it, so
restoring is not a reconstruction.

[TarikGul]

Secrets needed on paritytech/host-rust-core

All fifteen already exist as repo secrets on paritytech/polkadot-ios-community.
They need copying with their values, since GitHub cannot share secrets between
repositories. One person with access to that repository's settings can do all of
them.

secret	unblocks
CREDENTIAL_FILE_CONTENT	Firebase distribution, builds installable on a device
FIREBASE_APP_ID	Firebase distribution
GOOGLE_SERVICE_INFO_RELEASE_BASE64	release and nightly builds
GOOGLE_SERVICE_INFO_SAFETY_BASE64	safetynet builds, a separate Firebase app
ASC_KEY_BASE64	TestFlight, safetynet, device registration, signing maintenance
SCW_ACCESS_KEY	S3 storage of distributed builds
SCW_SECRET_KEY	S3 storage of distributed builds
ALLURE_TOKEN	test reporting
SENTRY_AUTH_TOKEN	symbol upload
NOTIFICATION_BOT_TOKEN	build notifications
NOTIFICATION_BOT_URL	build notifications
CI_MATRIX_ROOM_IDS	build notifications
TESTFLIGHT_DISTRIBUTION_LINK	links carried in notifications
TESTFLIGHT_SAFETY_DISTRIBUTION_LINK	links carried in notifications
WEB_PAGE_DISTRIBUTION_LINK	links carried in notifications

CREDENTIAL_FILE_CONTENT and FIREBASE_APP_ID are the smallest useful pair.
They turn the simulator-only preview into a build that installs on a phone.

Already set

ASC_ISSUER_ID, ASC_KEY_ID, FASTLANE_RO_PAT,
GOOGLE_SERVICE_INFO_DEV_BASE64, KEYCHAIN_PASSWORD, MATCH_PASSWORD

Everything the pull request checks need, which is why ios-pr.yml is live.

Not needed

MELD_BASIC_AUTH_TOKEN and SENTRY_DSN are not build-blocking: both are
declared required: false with an empty default.

FASTLANE_RW_PAT and WEB_PAGE_SAFETY_DISTRIBUTION_LINK are referenced by
update-signing-data and nightly-distribution but are not set on the app
repository either, so either they are unset upstream and those steps run empty,
or they live somewhere not visible here. Worth resolving before turning those two
workflows on.

[TarikGul]

Done, closing. The cutover landed today across #820, #833 and paritytech/polkadot-ios-community#146.

Against the list here: the app repository stopped releasing everything except Safetynet, which was the prerequisite for all of it. The branch filters target main, and the only develop left is a default in ios-safetynet-distribution, which stays held. The stale dispatch filenames are fixed, and a 404 on the default branch now fails rather than warning, so a pipeline cannot report success having dispatched nothing. The import was refreshed to the app repository's tip first.

Of the six guards from #787, three are gone. Three stay, and not because the cutover is unfinished: Safetynet ships from the app repository, and update_signing_data and register_device stay there too so one repository writes provisioning state rather than two on schedules.

Four more guards were added deliberately. The Safetynet leg inside the nightly, because that pipeline builds both configurations and refusing it at the choke point would have turned every run red. And the three notification jobs, because the action exits non-zero when given neither a Matrix room nor a Telegram chat, which would have reported a delivered build as a failed run.

That covers the one item left open here, provisioning the secrets. Eleven of twenty-two are unset. The notification ones are not being provisioned at all: a relay we run ourselves replaces them, and the jobs are held until it exists. SENTRY_AUTH_TOKEN is absent and the symbol upload now skips rather than failing a lane whose delivery already happened. FASTLANE_RW_PAT belongs to the app repository under this split, and is tracked on #681 along with the discovery that signing rotation there has been failing since 2026-08-25.

Anything further is a specific piece of work with its own issue rather than a step in turning these on.