perry setup ios only provisions for distribution — add development-profile + device-registration support for on-device testing

Perry version: 0.5.1019.

Gap

perry setup ios configures App Store / TestFlight distribution: it stores the App Store Connect API key (p8 / key-id / issuer-id), team ID, and produces an App Store distribution provisioning profile (get-task-allow: false, no ProvisionedDevices).

That profile cannot install on a physical device for development. So the otherwise-smooth perry compile --target ios → install-on-my-phone loop dead-ends: the produced main.app either isn't signed, or signing it with the distribution profile yields an app iOS refuses to launch on a development device.

To actually run on a connected iPhone today you must leave Perry entirely and hand-craft, in the Apple Developer Portal:

1. Register the device UDID (Devices → +).
2. Create an iOS App Development profile for the App ID, with an Apple Development: cert and the device included.
3. Download it, point perry.toml :: [ios] provisioning_profile at it, switch signing_identity to the development cert.
4. Re-sign the bundle and push with xcrun devicectl.

Perry already holds everything needed to automate steps 1–2 (the App Store Connect API can register devices and create development profiles with the stored p8 credentials).

Ask

A development-signing path, e.g.:

perry setup ios --development         # create/refresh an iOS App Development profile via ASC API
perry run src/main.ts --target ios    # build + dev-sign + install + launch on the connected device

Concretely:

• perry setup ios --development (or a perry devices register + perry profile create --development): use the ASC API to register the currently-connected device's UDID and mint an iOS App Development profile for the manifest's bundle_id, saving it next to the distribution one (e.g. ~/.perry/<bundle>_dev.mobileprovision).
• perry compile/run --target ios should prefer the development profile + an Apple Development: identity when the target is a real device and distribute isn't being invoked, and sign the bundle (today perry compile --target ios emits an unsigned main.app and only prints simctl instructions).
• perry run --target ios should then drive xcrun devicectl device install + process launch on the connected device — the on-device equivalent of the existing simctl launch path.

Related friction (same workflow)

• App Group identifiers aren't auto-registered. With [ios] app_group = "group.com.example.shared" in perry.toml, the App Group still has to be manually created in the portal as an App Groups identifier and then attached to the App ID before a profile referencing it will validate — otherwise it's not even selectable in the capability picker. Perry could register the App Group via the ASC API when it's declared in the manifest (it already auto-emits the entitlement at appGroupSet/Get/Delete on iOS is an in-process HashMap stub — wire UserDefaults(suiteName:) (follow-up to #675) #1178).
• perry compile --target ios printing only simctl (simulator) install instructions reinforces the impression that device install isn't a supported path.

Why it matters

"Compile my TS app and run it on my iPhone" is the single most common inner-loop for a mobile framework. Right now Perry nails the build but stops at an unsigned bundle + simulator-only instructions, forcing a multi-step manual detour through the Apple portal for every new bundle ID. Distribution is automated; development should be too.