Fix the App Store Connect upload rejections: MediaPipe bundle versions and the DAT URL scheme

[straff2002]

Unblocks TestFlight. An upload of 2026.8 surfaced five messages; one is the actual blocker, the rest are long-standing advisories.

The blocker: MediaPipe frameworks have no version keys

Google ships MediaPipeTasksCommon and MediaPipeTasksVision with neither CFBundleVersion nor CFBundleShortVersionString, and fetch-mediapipe-frameworks.sh only downloaded and moved them — so App Store Connect rejected both bundles ("is invalid. The Info.plist file is missing the required key"). These are hard errors, and new: they arrived with the Plan CK MediaPipe vendoring, so every archive since then would have failed the same way.

The script now stamps the pinned version into every slice with plutil -replace, which adds the key when absent and is therefore idempotent. It also runs on the already-fetched path, so existing checkouts and warm CI caches repair themselves without a 1.2 GB re-download — and since ci_scripts/ci_post_clone.sh calls the same script, Xcode Cloud is covered.

Audited the other five embedded frameworks while here — MWDAT ×3, WebRTC, onnxruntime all carry both keys — so this is the whole of it.

Verified: all four framework slices now carry 1.0.0 for both keys; a re-run is a clean no-op and repairs in place without re-downloading.

Also: the DAT URL scheme was a hardcoded placeholder

Info.plist declared the literal mwdat-YOUR_META_APP_ID while the MWDAT dict seventy lines below correctly used $(MWDAT_META_APP_ID). Underscores aren't legal in a URL scheme, which is what the validator objected to.

This is validation-noise cleanup, not a functional fix. Glasses registration has worked fine for the last month with the placeholder in place, so nothing depends on this scheme today — the SDK uses MWDAT.MetaAppID, which always resolved correctly. Changing it to mwdat-$(MWDAT_META_APP_ID) simply matches Meta's convention and silences the advisory.

Verified: processed Info.plist resolves to mwdat-688603774243722.

Not blockers (no action needed)

• "Unsupported SDK or Xcode version" — advisory only. As the message itself states, beta SDKs are fine to build and upload to App Store Connect; only App Store submission requires an RC. Beta-built TestFlight builds have been working for a month.
• The seven "Upload Symbols Failed" messages — warnings, not rejections. The vendored frameworks ship without dSYMs, so crashes inside them won't symbolicate. Nothing to fix in our code.

Note for CI archives

The scheme fix only takes effect when MWDAT_META_APP_ID holds the app id at archive time. Locally that comes from project.local.yml. Xcode Cloud has no such file, so project.base.yml's YOUR_META_APP_ID default would apply and the advisory would reappear — cosmetic, given the above, but worth setting as an Xcode Cloud environment variable if you want a clean validation report.

Branched off main rather than stacked on #305 so it isn't gated behind that review.

🤖 Generated with Claude Code

[straff2002]

Verification follow-up: the build finished and the processed Info.plist confirms the substitution resolves correctly.

CFBundleURLSchemes[0] = mwdat-688603774243722
CFBundleURLSchemes[1] = openglasses
MWDAT.MetaAppID       = 688603774243722

(Debug simulator, BUILD SUCCEEDED.) Both fixes in this PR are now directly verified rather than reasoned — the caveat in the Verification section is resolved.

Still outstanding for a CI archive: Xcode Cloud has no project.local.yml, so MWDAT_META_APP_ID falls back to project.base.yml's YOUR_META_APP_ID and the scheme would be invalid again. That needs the app id set as an Xcode Cloud environment variable.

[straff2002]

Correcting the triage in my earlier description (body now updated).

I had listed the Xcode-beta message and the URL-scheme message as blockers. Neither is:

• Xcode beta is fine for TestFlight. Apple's own text says beta SDKs may be used to build and upload to App Store Connect; only App Store submission needs an RC. Beta-built TestFlight builds have been shipping here for a month.
• The URL scheme is not a functional bug. I speculated that if the DAT SDK used mwdat-<appid> for its registration redirect then glasses login had been broken all along. It hasn't — registration has worked for a month with the placeholder, so nothing uses that scheme today. MWDAT.MetaAppID is what the SDK reads, and that always resolved correctly. The change is worth keeping (underscores are illegal, and it matches Meta's convention) but it is validation-noise cleanup, not a fix for anything user-facing.

The one real blocker is the MediaPipe missing-version-keys rejection, which is a hard ITMS error and new with the Plan CK vendoring. That is fixed and verified.