fix: stamp required version keys into GutenbergKitResources framework Info.plist

[jkmassel]

What?

GutenbergKitResources.framework's Info.plist was missing CFBundleShortVersionString and MinimumOSVersion, which App Store Connect requires on every embedded framework. This adds those keys (plus CFBundleVersion), sources every value from a single manifest, and adds a post-build check so the plist can't silently drift again.

Why?

build_xcframework.sh hand-writes the framework Info.plist with only four keys — CFBundleExecutable, CFBundleIdentifier, CFBundleName, CFBundlePackageType. codesign (fastlane xcframework_sign) doesn't validate version keys, so the deficient framework passes signing, zips, and publishes to the CDN unnoticed. altool is the first tool in the chain that validates embedded-framework plists — so the failure only surfaces at a consuming app's TestFlight upload, three hops downstream:

• missing CFBundleShortVersionString → altool 90057
• missing MinimumOSVersion → altool 90360

This blocked a wordpress-ios TestFlight upload: build 33156.

Note: this fix is forward-only — the XCFramework already on the CDN still carries the bad plist, so it won't unblock a consumer on its own. It needs a new GutenbergKit release carrying this change, then a consumer bump to pick it up.

How?

1. Stamp the required keys

The heredoc now also emits CFBundleShortVersionString, CFBundleVersion, MinimumOSVersion, and CFBundleInfoDictionaryVersion. CFBundleVersion wasn't in altool's error list, but a framework carrying CFBundleShortVersionString without it is malformed by convention — cheaper to include now than to eat a second upload round-trip.

2. Single source of truth, fail-closed

• CFBundleShortVersionString / CFBundleVersion ← package.json version
• MinimumOSVersion ← Package.swift's declared iOS platform, via swift package dump-package | jq (SwiftPM normalizes .v17 → "17.0", the exact format the key wants)

Both abort the build if the value can't be read, rather than stamping a silently-wrong placeholder — a wrong-but-present version is exactly the drift we want to prevent. MINIMUM_IOS_VERSION is no longer hardcoded, so the dylib link target (-target arch-apple-ios${MINIMUM_IOS_VERSION}) tracks Package.swift too.

3. Verify before the artifact leaves the step

After create-xcframework, verify_framework_plist runs against every shipped slice and exit 1s unless: plutil -lint passes, CFBundleShortVersionString matches package.json, CFBundleVersion is present, and MinimumOSVersion matches. A dropped or stale key now reddens GutenbergKit's own build-xcframework job instead of a downstream App Store upload.

Testing Instructions

1. make build-resources-xcframework (or ./build_xcframework.sh).
2. Confirm the new --- Verifying framework Info.plist step prints OK: for each slice and the script exits 0.
3. Inspect a slice's plist and confirm the keys resolve:

   plutil -p build/GutenbergKitResources-*.xcframework/ios-*/GutenbergKitResources.framework/Info.plist
   

   Expect CFBundleShortVersionString = the package.json version and MinimumOSVersion = 17.0.
4. Negative check: temporarily edit package.json's version, rebuild, and confirm the verification step fails the build with a CFBundleShortVersionString ... does not match error.

Accessibility Testing Instructions

N/A — build tooling only, no UI change.

[wpmobilebot]

XCFramework Build

This PR's XCFramework is available for testing. Add the following to your Package.swift:

.package(url: "https://github.com/wordpress-mobile/GutenbergKit", branch: "pr-build/551")

_{Built from 352520d}

[crazytonyli]

Use jq instead of node?

[jkmassel]

Oh yeah, nice. Done in 352520d