Advanced Data Protection accounts cannot obtain a CloudKit web-auth token — document and track

[leogdion]

Tracking issue for the Advanced Data Protection (ADP) findings from #392 (scenarios B1a/B2/B3). Split out so #392 can close on the encrypted-field implementation.

What was established (2026-09-14, container iCloud.com.brightdigit.MistDemo)

• An iCloud account with ADP enabled cannot obtain a ckWebAuthToken through the CloudKit JS sign-in popup, in Safari or Chrome, with iCloud web access on and a trusted device armed via icloud.com. Apple ID password + two-factor device approval succeed; CloudKit's own exchange GET setup.apple-cloudkit.com/setup/ws/1/oauth/validateToken then returns 200 {"status":13} and no session. Apple's ckauth.js handles statuses 0 (success), 7 (terms), 11 (poll requestPCS) and 12 ("iCloud Data Web Access is Off"); 13 falls into the generic "Authentication Error" page and reports CKAUTHunknownError.
• The same ADP account on icloud.com gets per-app key release (setup.icloud.com/setup/ws/1/requestWebAccessState → enableDeviceConsentForPCS → requestPCS {"appName":"notes3"}), after which Notes reads its encrypted fields over /database/1/com.apple.notes/production/private/… normally. That is Apple's documented allow-list of iCloud.com services; a third-party container is refused one step before that loop.
• Consequence: nothing in MistKit's request/response path can observe or handle the ADP condition. The only API-side shape reported anywhere is ACCESS_DENIED / "private db access disabled for this account" from a token minted before ADP was enabled, which CloudKitError.accessDenied(reason:) already carries. Public DB + server-to-server is unaffected.

Full write-up with sources, HAR sequences and the ckauth.js status table: .claude/docs/research/adp-web-auth-signin.md (branch 392-encrypted-fields).

Follow-ups

• DocC note on encrypted fields: web-auth is unobtainable for ADP accounts, what the user sees, and that turning ADP off is the documented recovery (lands with the Research Encrypted Fields #392 PR).
• Recovery check: turn ADP off on the test account, confirm the popup signs in again and earlier records read back (validates Apple's "returns the account to standard data protection").
• Optional — standard-account DevTools capture of the popup to record whether a healthy validateToken returns status 0 directly or 11 + requestPCS polling (turns the reading of 13 into a comparison).
• Optional — "token minted before ADP" experiment: sign in with ADP off using Keep me signed in, enable ADP, call the private DB via mistdemo probe-encrypted --skip-write; capture the API-side error (expected ACCESS_DENIED). Decides whether any docs wording on accessDenied is warranted.
• Optional — Feedback Assistant / DTS request for a documented statement that CloudKit Web Services and CloudKit JS cannot authenticate ADP accounts.

Not worth pursuing (see the research doc for why): other browsers or environments, waiting for key rotation, CKTool JS, icloud.com-in-the-same-browser.

Refs #392.