GHSA-4vrg-r928-h5vv

### Impact Under concurrency, `CheckPermission` and `CheckBulkPermissions` can return `PERMISSIONSHIP_HAS_PERMISSION` for a (resource, permission, subject) whose correct answer is `PERMISSIONSHIP_CONDITIONAL_PERMISSION`.

You are impacted if **all** of the following hold:

1. Your schema has a permission combining relations with an intersection or exclusion, where a subject reaches it through a caveated branch and a non-caveated branch. For example:

```zed definition user {}

caveat some_caveat(somecondition int) { somecondition == 42 }

definition document { relation reader: user | user with some_caveat relation writer: user relation banned: user permission has_permission = (reader & writer) - banned } ```

2. A subject reaches the permission via the caveated edge:

``` document:firstdoc#reader@user:caveatedreader[some_caveat] document:firstdoc#writer@user:caveatedreader ``` 3. Your workload issues `LookupResources` with a `context` request parameter, concurrently with `CheckPermission/CheckBulkPermissions` for the same subject/resource, and 4. The dispatch result cache is enabled. When all of the above are true, there is an intermittent window in which:

`CheckPermission(document:firstdoc, has_permission, user:caveatedreader)` → HAS_PERMISSION (incorrect; should be CONDITIONAL_PERMISSION)

`CheckPermission(document:firstdoc, has_permission, user:caveatedreader, context = {"somecondition": 41})` → HAS_PERMISSION (incorrect; should be NO_PERMISSION)

### Patches

v1.54.0

### Workarounds Disable the dispatch result cache (`ClusterDispatchCacheConfig` and `DispatchCacheConfig`)