CloudKit Production RecordSave fails on _pcs_data (BAD_REQUEST) — reproducible across 2 Apple IDs, works fine in Development

Summary of my issue:

CloudKit sync works perfectly in the Development environment, but every single record save to Production fails identically — every build, two different Macs, two different networks, and now under two different, unrelated Apple IDs. The failure isn't in my own record types; it fails on Apple's internal _pcs_data system record, which blocks the entire save (my app's real records included) from ever completing. Because it reproduces under a second, unrelated Apple ID, this doesn't look like account-specific corruption — it looks like broken server-side state on this container's Production environment itself.

Exact error I'm seeing:

Console.app (identical every occurrence):

CoreData+CloudKit: -[NSCloudKitMirroringDelegate _requestAbortedNotInitialized:] (2192): <private> – Never successfully initialized and cannot execute request '<private>' due to error: Error Domain=CKErrorDomain Code=2 UserInfo={ContainerID=<private>, NSDebugDescription=<private>, CKPartialErrors=<private>, RequestUUID=<private>, NSLocalizedDescription=<private>, CKErrorDescription=<private>, NSUnderlyingError=0xa0b048810 {Error Domain=CKInternalErrorDomain Code=1011 UserInfo={CKErrorDescription=<private>, NSLocalizedDescription=<private>, CKPartialErrors=<private>}}}

CloudKit Dashboard → Production → Monitor → Logs (5+ RecordSave attempts across days/machines/accounts):

Apple ID #1:

json { "database": "PRIVATE", "zone": "com.apple.coredata.cloudkit.zone", "userId": "_e7c2879989e20df06db9ddb272805ea7", "operationType": "RecordSave", "platform": "Mac", "overallStatus": "USER_ERROR", "error": "BAD_REQUEST", "interfaceType": "NATIVE", "returnedRecordTypes": "_pcs_data" }

Apple ID #2 (unrelated account, tested later):

json { "database": "PRIVATE", "zone": "com.apple.coredata.cloudkit.zone", "userId": "_5b6b9a3c5c508babc44894d9f9d324e7", "operationType": "RecordSave", "platform": "Mac", "clientOS": "OSX;26.5.x", "overallStatus": "USER_ERROR", "error": "BAD_REQUEST", "interfaceType": "NATIVE", "returnedRecordTypes": "_pcs_data" }

Every other operation type in the same sessions succeeds normally: ZoneFetch, ZoneSave, RecordFetch, SubscriptionCreate, AssetUploadTokenFetch, ZoneChanges, and DatabaseChanges all return overallStatus: SUCCESS. Only RecordSave fails, always on _pcs_data, for both accounts.

My best guess...:

_pcs_data is Apple's internal Protected Cloud Storage record, used to wrap the encryption keys NSPersistentCloudKitContainer needs before it can write anything to a zone (automatic for any CoreData/SwiftData + CloudKit app, independent of whether any schema field is manually marked "Encrypted"). If that record fails to save, the zone can never finish initializing, which produces exactly the "never successfully initialized" error above. Since Development works fine and Production fails identically for two completely unrelated Apple IDs on the same container, the broken PCS/key-wrapping state appears to live on this container's Production environment itself, not on any one account.

What I've tried so far:

Entitlements verified correct via codesign -d --entitlements :-, 4 separate times across different signing/provisioning states (Production icloud-container-environment, correct container/team, CloudKit + CloudDocuments services) Push Notifications / aps-environment: added, enabled on the App ID, provisioning profile regenerated — no effect, and confirmed not required for the core mirroring path anyway Schema deployment: CloudKit Dashboard "Deploy Schema Changes to Production" shows an empty diff (0 record types/indexes/security roles) — Production already matches Development exactly No fields marked "Encrypted" in any record type iCloud app permission for this app confirmed ON in System Settings iCloud Keychain "Sync this Mac" toggled off then back on — no effect Exactly 1 iCloud container assigned to the App ID, no duplicates Tested on 2 Macs, 2 networks, 2 unrelated Apple IDs — identical failure every time Development environment works perfectly on every test, including a 31.5MB audio asset upload Advanced Data Protection toggled on then off — no effect CloudKit Dashboard "Reset Environment" — not offered for Production (Apple restricts this to Development only)

How to Reproduce:

I built a minimal (~150 line) SwiftData + CloudKit project using the same bundle ID, team, and container as my real app: a single @Model class with one field, ModelConfiguration(cloudKitDatabase: .automatic), and a button that inserts and saves a record, observing NSPersistentCloudKitContainer.eventChangedNotification and displaying any error in its own UI. Archived and exported with Production entitlements (not a Debug run), it reproduces the same failure family while working perfectly in Development. Happy to share it if useful.

What I'm asking for:

This is 100% reproducible, isolated to Production for this specific container, and reproduces under two unrelated Apple IDs with every client-side configuration verified correct. Has anyone else seen _pcs_data RecordSave fail with BAD_REQUEST in Production only? Is there a known fix, or does this need Apple to inspect/reset the server-side PCS state for this container's Production environment?

Related threads:

I found a couple of related threads while searching before posting this. In Handling CKError.partialFailure with pcs_data errors, an Apple DTS engineer (Ziqiao Chen) explained that _pcs_data/BAD_REQUEST is normally transient and that NSPersistentCloudKitContainer retries automatically, so it usually isn't worth worrying about. That matches what I'd expect for an occasional blip — but in my case it's 100% reproducible, permanent, and blocks every save, which seems like a real deviation from that expected behavior rather than routine noise. I also found a CKShare thread with the exact same signature (RecordSave / BAD_REQUEST / returnedRecordTypes: _pcs_data in a Production private database) that appears to be unresolved, so I don't think I'm the only one hitting this.