My SwiftData app (NSPersistentCloudKitContainer mirroring, private database only) cannot save any record to its CloudKit Production environment, for any user. Development works flawlessly for the same devices, accounts, and code. Signature, from CloudKit Console Production logs: every RecordSave to zone com.apple.coredata.cloudkit.zone fails with overallStatus USER_ERROR, error BAD_REQUEST, returnedRecordTypes "_pcs_data". Reads and zone setup succeed in the same sessions (ZoneSave, SubscriptionCreate, DatabaseChanges, ZoneChanges). Zero successful RecordSaves have ever occurred in this container's Production environment. Facts established so far: 4 of 4 users fail identically (my account + 3 TestFlight testers on unrelated iCloud accounts, iPhone and iPad, iOS 26.6/26.6.x) — so this is not one account's Advanced Data Protection key state. Schema was deployed Dev to Production via Console; the Deploy sheet now reports zero pending changes, and Export Schema from BOTH environments yields identical record type sets. _pcs_data appears in neither export — it is a server-managed system type, so there is no developer action (Console or cktool) that can add it to Production. The model declares no encrypted attributes (allowsCloudEncryption appears nowhere). Entitlements verified with codesign on the shipped TestFlight binary: icloud-container-identifiers, icloud-services=CloudKit, production environment — all correct. Client-side the failure is silent: CKAccountStatus is .available, the container initializes, no error surfaces; the mirroring delegate just stops exporting. Tried without effect: reboots, reinstalls, force-quits, per-app iCloud toggles; storage has ample headroom. This matches the signature in thread 838743 (FB23731287, FB24150787), where multiple developers report the same behavior, unresolved. Filed as FB24378074, which now carries: a CloudKit-profile sysdiagnose captured during a timestamped reproduction, the matching server-side requestId/operationId for that exact save (9265D1CA-86BF-4CEB-A432-43F3F39C891E / A2A2B0F98B389DF8), schema exports from both environments, and a full fault-elimination audit. Question for DTS: what makes a Production environment reject _pcs_data record saves that Development accepts, and what is the supported path to repair this container's Production PCS handling? A live TestFlight beta (a family app; device-to-device sync fully down for all users) is waiting on this. Happy to run further diagnostics on request — a minimal repro project against a fresh container is prepared. Case-ID: 21696635