CKQuery returns zero records while CKFetchRecordZoneChangesOperation returns 2275 in the same zone — container index corruption?

We have a production CloudKit container where every CKQuery against one specific user's private database returns zero records with no error. The records are present and readable by other means.

In a single app launch, against the same private custom zone on that account:

CKQuery, NSPredicate(value: true)     0 records, no error
CKFetchRecordZoneChangesOperation     2275 records
  (231 Inspection, 2040 InspectionPhoto, 2 Job, 2 cloudkit.share)

Queries return zero for every record type, in both the default zone and the custom zone, and with both NSPredicate(value: true) and a field predicate on an indexed queryable field. Account status is .available and userRecordID resolves normally. No client change preceded this. Other users on the same container and the same binary are unaffected. The user did not delete anything; the trigger appears to have been an unexpected iCloud sign-out mid-session.

The same account's private default zone additionally cannot be enumerated at all:

CKError.serverRejectedRequest (15)
"AppDefaultZone does not support getChanges call"
CKInternalErrorDomain code 2027

We understand getChanges is not supported on the default zone. Noting it because our Company record type lives there, so its state cannot be verified by any index-free path, and an empty query result there is uninterpretable.

This looks like the container index loss described by DTS in thread 775063 ("I ever saw some CloudKit containers losing their indices, and so a query to the container may not return the right result set").

Filed as FB24641992 with a full diagnostic log attached, including the container identifier, team identifier and the affected user record ID.

We have shipped a client-side workaround that falls back to zone enumeration whenever a query returns zero, so the user is unblocked, but the index is still broken and that account now runs entirely on fallback paths.

Question: is there a way to get a container re-indexed for a specific account, and is there anything we can do client-side to detect or avoid this state? We could not produce a focused sample project for a code-level support request because the fault is server-side account state, not client code — the same calls on a healthy account in the same container from the same binary return matching results.