Korrektur: das Apple-Konto ist ein kostenloses Personal Team

Der vorige Commit ging von einer bezahlten Mitgliedschaft aus und nannte als
Ausweg, die UDID auf developer.apple.com einzutragen. Das ist falsch.

Xcodes eigener Zwischenspeicher belegt das Gegenteil:
isFreeProvisioningTeam = 1, teamType = "Personal Team". Damit gibt es gar
keine Geräteverwaltung im Portal -- ein Gerät wird ausschließlich dadurch
bekannt, dass es angeschlossen und vertraut ist. Zusätzlich verfallen Profil,
App-ID und Geräteeintrag alle 7 Tage.

Auch die ältere Behauptung weiter oben in AGENTS.md ("Paul has an Apple
Developer Program") ist damit als falsch markiert.

Offen und bewusst als ungeprüft vermerkt: ob -exportArchive mit einem
Personal Team überhaupt eine brauchbare .ipa liefert. Der direkte Weg aufs
angeschlossene Gerät steht als Rückfallebene im Skriptkopf.

AGENTS.md

@@ -1430,7 +1430,8 @@ wraps the web app for iPhone; a PWA home-screen install is the accepted intermed
       panel fix and feature from the six days since (HIG audit rounds, receipt upload, trip
       editing, Inspektion forecast, ...) existed only in `homeassistant/www/audi-dashboard-app.js`.
       User decision: port everything now, before any native build work (Android build itself
-      deprioritized/uncertain per the user - Paul has an Apple Developer Program and will help with
+      deprioritized/uncertain per the user - Paul has an Apple Developer Program **[WRONG, see
+      section AI: it is a free Personal Team, not a paid membership]** and will help with
       iOS signing). Audited both codebases field-by-field (not by diffing the panel's CSS/markup,
       which doesn't transfer to `@audi-dash/ui` components) and found six real, mechanically
       distinct gaps, all fixed:
@@ -4612,22 +4613,43 @@ What was verified on this machine (Xcode 26.4, Node 22.20, `main` at `2026.8.28.
   nothing but provisioning is missing.
 
 **The blocker, verbatim from Apple:** `Communication with Apple failed: Your team has no devices
-from which to generate a provisioning profile.` The developer account authenticates fine (Xcode
-reached Apple and got a real answer, not an auth error) — team `RMACS9VLS4`, certificate
+from which to generate a provisioning profile.` The account authenticates fine (Xcode reached Apple
+and got a real answer, not an auth error) — team `RMACS9VLS4`, certificate
 `Apple Development: paul.nothaft@me.com (C9L892Z59P)`, valid until 2027-07-17. Apple issues a
 development profile only for **named devices**, and this team has none registered. No iPhone is
-connected (`xcrun devicectl list devices` → none), no device was ever paired with this Mac (no
-`~/Library/Developer/CoreDevice`, no iOS DeviceSupport), and no App Store Connect API key exists
-to register one remotely. There is no route around this from a machine with no phone attached:
+connected (`xcrun devicectl list devices` → none) and no device was ever paired with this Mac (no
+`~/Library/Developer/CoreDevice`, no iOS DeviceSupport). There is no route around this from a
+machine with no phone attached:
 
 - development / ad-hoc profiles both require registered UDIDs;
 - an App-Store-method export needs no devices but produces an IPA that iOS refuses to sideload;
 - a locally `codesign`-ed `.app` without an embedded profile will not install either.
 
-**What to do (owner, one minute, once):** connect the iPhone by cable and tap "Trust", then run
-the script below — Xcode registers the UDID itself via `-allowProvisioningUpdates`. Alternative if
-the phone is elsewhere: add its UDID under developer.apple.com → Certificates, Identifiers &
-Profiles → Devices. After that the device stays registered and the step never repeats.
+**Correction, same day: this is a FREE account, not a paid membership.** Xcode's own cache says so
+— `defaults read com.apple.dt.Xcode` → `IDEProvisioningTeamByIdentifier`:
+`teamName = "Paul Nothaft (Personal Team)"`, `teamType = "Personal Team"`,
+**`isFreeProvisioningTeam = 1`**. The note further up this file claiming "Paul has an Apple
+Developer Program" (section on the 2026-08-17 port) is therefore **wrong** and must not be relied
+on. Consequences, all confirmed against Apple's membership comparison and the free-provisioning
+limits:
+
+- **There is no portal route to register a device.** Certificates, Identifiers & Profiles device
+  management is a paid-membership feature. A free team registers a device only by having it
+  **physically connected to this Mac and trusted**; Xcode then does it via
+  `-allowProvisioningUpdates`. So "add the UDID on the website" is not an option here.
+- **Everything expires after 7 days** — provisioning profile, App ID and device registration alike.
+  The app stops launching and has to be rebuilt and reinstalled, forever, every week.
+- Ceilings: 3 devices per platform, 10 App IDs per 7 days.
+- Whether `-exportArchive` even yields a usable `.ipa` for a free team is **untested and doubtful**
+  — free provisioning is built around "Run straight onto the connected device" from Xcode, not
+  around exporting a redistributable archive. If the export step fails once a phone is attached,
+  install directly instead of debugging the export.
+
+**What to do (owner):** connect the iPhone by cable, tap "Trust", then run the script below. That
+is the only path with this account type. If the weekly re-install turns out to be intolerable, the
+paid Apple Developer Program (99 €/year) is what buys the 1-year signature, portal-side UDID
+registration without the phone present, and 100 devices — `UMSETZUNGSPLAN.md` Phase 10 already
+flagged this as an owner decision, and it is now a decision with a known answer on one side.
 
 **What was built instead of a hand-clicked Xcode signature:** `companion-app/scripts/ios-signieren.sh`
 — build → `cap sync` → signed archive → `.ipa` export, one command. It exists because `ios/` is