mix mob.release --ios can't produce a build installable on one's own device (beta-reports-active is always set) #158

What happens

release_device.sh always signs with beta-reports-active = true. That entitlement is only allowed by an App Store profile. Signing a release with a development (or ad hoc) profile, via ios_dist_sign_identity / ios_dist_profile_uuid, which resolve_distribution_signing/1 accepts as given, produces an .ipa that the device refuses at install:

xcrun devicectl device install app --device <id> _build/mob_release/MyApp.ipa
→ 0xe8008015 (A valid provisioning profile for this executable was not found.)

Re-signing the same .app without beta-reports-active installs and runs fine.

Why a release build on one's own device matters

A release build is the only build without the in-app EPMD, and the in-app EPMD of dev builds ends the app at each unlock of an iPhone (GenericJam/mob#215). For "development-only builds to your own device", release.ex points to mix mob.deploy --native, which is the build affected by #215. Today the only way to run a release build on one's own iPhone is TestFlight: an Apple Distribution certificate, an App Store profile, an upload and a processing round trip.

We use one daily on our own phone (mob 0.9.27, mob_dev 0.7.31, iPhone 16 Pro, iOS 26.6.1). It survives lock/unlock where the dev build doesn't. Our local workaround drops the entitlement when the profile lists devices.

Proposed change, two possible shapes

Release.parse_mobileprovision/1 already reports provisioned_devices? and provisions_all_devices?, so the decision can be a small pure function passed to the script:

1. Detect from the profile. No beta-reports-active when the chosen profile lists devices or provisions all devices (development, ad hoc, enterprise), unchanged for an App Store profile. The task prints that the .ipa is for devicectl, not TestFlight. Nothing to configure, but a wrong profile silently yields a non-TestFlight build.
2. An explicit mode, e.g. mix mob.release --ios --device or a mob.exs key. It signs for the device and refuses an App Store profile in that mode; without it, the current behaviour stays and a device profile is refused before the build rather than at install.

Which shape would you prefer? Happy to send the PR, with tests on the three profile kinds, once you've chosen.

Related: #157 (the release also left out plugins' Info.plist keys, found on the same path).