iOS: fail fast when CN1Widgets (external surfaces) has no provisioning profile under manual signing #6008

Problem

An app that uses external surfaces (com.codename1.surfaces.*, i.e. home-screen widgets or live activities) gets a generated CN1Widgets WidgetKit extension target in its iOS build. With manual signing, that target needs its own App ID (<package>.CN1Widgets, with the App Groups capability) and its own provisioning profile. This is documented in External Surfaces → Signing.

When the developer supplies only the app's own profile, nothing stops the build early. The cloud build runs until Xcode reaches the extension target, then fails with:

<project>.xcodeproj: error: Provisioning profile "<app profile name>" has app ID "<package>",
which does not match the bundle ID "<package>.CN1Widgets". (in target 'CN1Widgets' ...)

The message never names the fix, which is the ios.appext.CN1Widgets.provisioningURL build hint, a codename1.ios.{debug,release}.appext.CN1Widgets.provision setting, or re-running the Certificate Wizard. A developer who doesn't know the extension exists can't tell why their working profile is wrong.

Why it isn't caught today

IOSProvisioningPreflight.checkGeneratedExtensions already does this check for the generated document-provider extension: it warns locally, before any cloud build is spent. Its javadoc says CN1Widgets "could join the table below" and was left out on purpose, until a change could be "verified against real projects". This is that real-project evidence.

Unlike the document provider, which a build hint enables, CN1Widgets is gated on actual usage. IPhoneBuilder sets usesSurfaces when a class references com/codename1/surfaces/. So the preflight would need the same signal, from a scan of the compiled classes or from an equivalent check.

Suggested fix

1. Local preflight (catches it before a build is spent). Add CN1Widgets to checkGeneratedExtensions. When the app references com.codename1.surfaces.*, the build uses manual signing, and no profile is configured for the extension (neither the .provision setting nor the provisioningURL hint), report the problem. The message should name the App ID to create (<package>.CN1Widgets with App Groups), the hint or setting that supplies its profile, and the Certificate Wizard.
2. Builder, as a backstop for older clients. When usesSurfaces is set under manual signing and no CN1Widgets profile was supplied, stop the iOS build before Xcode runs with the same message, instead of letting xcodebuild fail on the bundle-ID mismatch.
3. Automatic signing and ios-source. Both are unaffected (Xcode provisions the target itself) and must stay silent.

Tests: a preflight unit test per case (surfaces used plus manual signing plus no extension profile → problem reported; extension profile present → no problem; surfaces unused → no problem; automatic signing → no problem).