iOS 0.5.212: SIGABRT as the setup wizard enters the AI-configuration step (with-AI pass; not #47's roster timeout)

[emooreatx]

iOS simulator, 0.5.212, with-AI setup: SIGABRT 1.7 s after the wizard leaves JOIN_FEDERATION for the AI step (gate run https://github.com/CIRISAI/CIRISAgent/actions/runs/34272658734, CIRISAgent release/2.11.0 @ 67404f6c0, iPhone simulator, ciris-server 0.5.203). This is not #47's roster timeout — the runtime had been READY for 20 s.

ios-oslog.log:

20:32:18.160 iosApp[28487]: (Python) Node fold: OWNERSHIP UNCLAIMED — one-time CLAIM PIN: G67C-YHDM …
20:32:39.954 launchd_sim: [UIKitApplication:ai.ciris.mobile[ca4b] [28487]:] exited due to SIGABRT | sent by iosApp[28487], ran for 36620ms
20:32:39.954 launchd_sim: … service has crashed 1 times in a row (last was not dirty)

kmp_app.log (last lines the app wrote):

20:32:19.695 I/StartupViewModel: [STARTUP] === Startup sequence complete ===
20:32:19.706 I/StartupScreen: [PHASE] READY (READY)
20:32:19.748 I/CIRISApiClient: [getSetupStatus] Setup status: required=true, firstRun=true, configExists=false
20:32:20.018 W/LocalizationManager: Missing localization key: setup.ai_preference_question (lang=en, stringsKeys=273)
20:32:20.019 W/LocalizationManager: Missing localization key: setup.ai_preference_with (lang=en, stringsKeys=273)
20:32:20.019 W/LocalizationManager: Missing localization key: setup.ai_preference_with_desc (lang=en, stringsKeys=273)
20:32:20.019 W/LocalizationManager: Missing localization key: setup.ai_preference_without (lang=en, stringsKeys=273)
20:32:20.019 W/LocalizationManager: Missing localization key: setup.ai_preference_without_desc (lang=en, stringsKeys=273)
20:32:37.845 I/SetupScreen:  onNext clicked, currentStep=YOU, canProceed=true
20:32:37.848 I/CIRISApiClient: [mintUserIdentity] POST http://127.0.0.1:4243/v1/self/identity backend=(default) label=qa-node-1788899535
20:32:38.283 I/SetupScreen:  onNext clicked, currentStep=JOIN_FEDERATION, canProceed=true
20:32:38.284 I/SetupScreen:  Not final step - calling viewModel.nextStep()

Nothing after that; the abort lands as the AI-configuration step composes (oslog shows only keyboard input-view reloads and Metal shader compiles in the last second). The gate's next three steps then report the client's automation server stopped answering. Two observations for whoever holds the crash: the iOS bundle loaded 273 localization keys and is missing the setup.ai_preference_* set that the YOU step needs (the desktop bundle has them), and the no-AI pass on the same simulator — which never composes the AI step — completed 7/7 without incident.

The simulator's .ips crash report was not in our artifacts; I'm adding ~/Library/Logs/DiagnosticReports collection to the gate so the next run attaches it here. If you can reproduce locally, the with-AI wizard path on the simulator is the shortest route.

[emooreatx]

Not diagnosable from here yet — the .ips you are now collecting is the thing that will say why. Two candidates I can rule out so the next round does not spend time on them:

1. Not a stale XCFramework. I cancelled the iOS jobs on 0.5.210 and 0.5.211 to free runners, so neither release carries one — but v0.5.212's ios-xcframework completed and its XCFramework is attached. So if you built against 0.5.212's release assets, you had the matching framework and this is a real crash rather than a version-skew artifact. (If you resolved iOS from .211 and silently fell back, that is worth checking on your side — and it would be my doing, so tell me and I will stop cancelling those jobs.)

2. Not the missing setup.ai_preference_* keys. All three bundles in the tree — shared/desktopMain/resources, iosApp, androidApp/assets — are identical: 3923 flattened keys with all five setup.ai_preference_* present. And the AI step reads them through l10nOr(key, fallback), which returns the fallback when the value is blank or equal to the key, so a missing key renders English text rather than throwing.

That leaves your "273 loaded" as the interesting number, and I cannot explain it: 273 matches neither the 277 top-level keys nor the 3923 flattened ones. If the .ips does not name the throw, the loader's own count on iOS is where I would look next — something loaded a partial bundle, and that is a different bug from the crash even if they turn out to be related.

Nothing from me in the next cut for this one; I am not going to guess at a Kotlin/Native crash with the report a run away.