fix(ios): settle the build number before bundling the app

[CodyPChristian]

An iOS build stamps its self-update identity before it knows its build number, so every uploaded build ships an identity describing the previous build and devices never re-extract app.zip.

What happens

handle() calls bundleLaravelApp() first. That runs createAppZip(), which writes bundled.version and seals the .env carrying NATIVEPHP_APP_VERSION_CODE — both read from the config as it stands at that moment. Only afterwards does configureXcodeProject() → updateBuildNumber() resolve the real number from App Store Connect and stamp CURRENT_PROJECT_VERSION.

$this->bundleLaravelApp();                  // createAppZip() -> bundled.version  (OLD code)

if (! getenv(NATIVEPHP_XCODE_BUILD)) {
    if (! $this->configureXcodeProject()) { // updateBuildNumber() -> asks ASC     (NEW code)

The artifact

From a build uploaded to TestFlight:

Field	Value
CFBundleVersion	7 — what App Store Connect sees
CFBundleShortVersionString	1.0
bundled.version	1.0b2 — what decides re-extraction
app.zip → .env	NATIVEPHP_APP_VERSION_CODE=2

The upload succeeds because CFBundleVersion is new. On launch, AppUpdateManager.shouldUpdateWithVersion() compares bundled.version against the installed identity, finds 1.0b2 unchanged, and skips the update — so the device runs the previously extracted PHP.

The symptom in the field is that testers install a new TestFlight build, see the old app, and can only fix it by deleting and reinstalling. Nothing reports an error at any point, on either side, which is what makes it hard to attribute.

Android is unaffected, and shows the intended order

PackageCommand calls updateBuildNumberFromStore('android') before buildAndroid() writes the bundle, and updateBuildNumberFromStore() refreshes the runtime config as well as .env — so PreparesBuild stamps the correct identity.

An .aab and .ipa produced in the same session confirm the asymmetry:

	identity in bundle	store build number
.aab	1.0b7 ✅	7
.ipa	1.0b2 ❌	7

The change

updateAppVersion() and updateBuildNumber() now run in handle() before bundleLaravelApp(), under the existing NATIVEPHP_XCODE_BUILD guard, and are no longer called from configureXcodeProject().

Each still runs exactly once, so the non-store path cannot double-increment. Nothing else moves — the Xcode project is stamped from the same resolved value, just after the zip instead of before it.

Verifying

After building with --release --upload-to-app-store, the identity should match the build number:

unzip -qo NativePHP.ipa -d /tmp/ipa
APP=$(find /tmp/ipa/Payload -maxdepth 1 -name "*.app")
cat "$APP/bundled.version"                                        # expect 1.0b7
/usr/libexec/PlistBuddy -c "Print :CFBundleVersion" "$APP/Info.plist"   # expect 7

bundled.version should equal {CFBundleShortVersionString}b{CFBundleVersion}. Before this change it does not.