iOS: Reject merged-platform-ui-thread=mergeAfterLaunch - #190051

iOS runs with the platform and UI threads merged from launch and only implements fully-merged (kEnabled) threading. The mergeAfterLaunch approach starts the engine on a separate UI thread and merges it onto the platform thread once the root isolate is running.

The mergeAfterLaunch merge/unmerge code lives entirely in shell/common. The iOS embedder has never implemented it, and no iOS code has ever referenced it. On iOS, the flag was never wired up, and it isn't reachable through any supported configuration. The FLTEnableMergedPlatformUIThread Info.plist key only ever selects kEnabled or kDisabled.

The only way to reach it is the raw command-line flag, which nothing rejects today, so passing --merged-platform-ui-thread=mergeAfterLaunch slips through and produces a broken engine since:

• Shell::Spawn refuses kMergeAfterLaunch and returns null, so FlutterEngineGroup fails to spawn secondary engines outright.
• The CADisplayLink-backed vsync waiter registers on the run loop of whichever thread services the UI task runner when it's constructed. Under the merged model iOS actually ships (kEnabled) that's the platform thread, which is correct. Under mergeAfterLaunch it would be the temporary UI thread that the model abandons after launch, and which won't work.

This has been unsupported since mergeAfterLaunch was introduced.

Since every iOS Settings setting passes through FlutterDartProject, we can fail startup there with an FML_CHECK if this configuration is set. Normally this would live in shell/common/switches.cc but Android also passes require_merged_platform_ui_thread to SettingsFromCommandLine and still supports mergeAfterLaunch as a launch-latency optimization used by internal customers.

Also added a test that hints that mergeAfterLaunch is an intentional, supported configuration so that people like me don't try to lock it down again. See: #189893

This is part of cleanup work intended to simplify the iOS embedder prior to an eventual migration to the embedder API.

Issue: #112232

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the AI contribution guidelines and understand my responsibilities, or I am not using AI tools.
• I read the Tree Hygiene wiki page, which explains my responsibilities.
• I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
• I signed the CLA.
• I listed at least one issue that this PR fixes in the description above.
• I updated/added relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or this PR is test-exempt.
• I followed the breaking change policy and added Data Driven Fixes where supported.
• All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

If this change needs to override an active code freeze, provide a comment explaining why. The code freeze workflow can be overridden by code reviewers. See pinned issues for any active code freezes with guidance.

Note: The Flutter team is currently trialing the use of Gemini Code Assist for GitHub. Comments from the gemini-code-assist bot should not be taken as authoritative feedback from the Flutter team. If you find its comments useful you can update your code accordingly, but if you are unsure or disagree with the feedback, please feel free to wait for a Flutter team member's review for guidance on which automated comments should be addressed.