CKShare save fails with BAD_REQUEST on _pcs_data in Production private database

Saving a CKShare together with its root record in a custom zone in the user's private database fails on every attempt. The client sees CKError .serverRejectedRequest / .invalidArguments.

The CloudKit Console server log shows the failure is on the system record type _pcs_data, not on our own record type:

{ "database":"PRIVATE", "zone":"SharedStatusZone", "operationType":"RecordSave", "platform":"iPhone", "clientOS":"iOS;26.5.x", "overallStatus":"USER_ERROR", "error":"BAD_REQUEST", "requestId":"FDB0D10E-0B82-4C71-9262-90D9A2EA3787", "returnedRecordTypes":"_pcs_data" }

In the same session, ZoneSave and RecordFetch SUCCEED. Only the RecordSave that carries the CKShare fails.

Container: iCloud.com.nyeong.yakmeokping (Production) Device: iPhone, iOS 26.5.x

What we do (simplified)

let zone = CKRecordZone(zoneID: ownerZoneID)
_ = try await db.modifyRecordZones(saving: [zone], deleting: [])  // succeeds

let record = CKRecord(recordType: "MedStatus", recordID: ownerRecordID)
// plain String / Int64 / Date fields only

let share = CKShare(rootRecord: record)
share[CKShare.SystemFieldKey.title] = "..." as CKRecordValue
share.publicPermission = .none

_ = try await db.modifyRecords(saving: [record, share], deleting: [],
                               savePolicy: .allKeys, atomically: true)  // FAILS

User-visible symptom: UICloudSharingController shows "Cannot add people / Unable to create a link for sharing", and a Messages collaboration attachment spins forever, because no share URL is ever minted.

Already ruled out

1. iCloud sign-in - accountStatus() == .available immediately before the call.
2. iCloud Keychain - enabled on both the iPhone and a Mac on the same account.
3. Advanced Data Protection - OFF.
4. Leftover/broken share - also fails when no record exists yet (brand new).
5. UICloudSharingController - reproduced with a code path that never presents the controller and only performs the CloudKit save.
6. Schema - the record type and every field we write are deployed to Production.
7. Entitlements - com.apple.developer.icloud-services: (CloudKit), icloud-container-environment: Production, CKSharingSupported = true in Info.plist. Zone is a custom zone, not the default zone. Record and share are saved together, atomically, as documented.

Possibly related Two recent threads report CKErrorServerRejectedRequest limited to the PRIVATE database in Production, starting around July 25:

• "iCloud Dashboard returns Internal Error when querying records across all containers" - the author reported on July 30 that the service had been down for a few days and had since recovered.
• "CloudKit CKQueryOperation returns CKErrorServerRejectedRequest" (FB24046201) - failures since July 25, error code 15, CKInternalErrorDomain Code=2000, HTTP 500.

Those are read operations rather than a CKShare save, so they may be unrelated. Our failure still reproduces on July 31, after the other report says the incident was resolved. Note that developer System Status showed green throughout.

Questions

1. What does a BAD_REQUEST on _pcs_data during a CKShare save indicate? It appears to be the encryption key material for sharing rather than our own record.
2. Is there an account-level or container-level condition that can block PCS key provisioning?
3. Has anyone else seen CKShare creation (not query) failing in the same period?

Any pointer would be appreciated - the client-side CKError carries no server error description, so the console log above is all we can see.