As a photographer I want to know which program items can and cannot be photographed (DBAC Advanced)

[Blueprint](https://outline.con2.fi/doc/dimensions-based-access-control-dbac-BeLHvmYTzc#h-advanced-dbac-grant-security-shift-managers-visibility-to-people-working-in-security)

Whenever dimensions and their values are accessed, they should by default only show public dimensions.

For private dimensions, there should be a `includePrivate: true` or similar mechanism to ask for private dimension to be included. Private dimensions should be filtered using CBAC (#324) when asked for.

DBAC should allow event admins to share a number of private dimensions with volunteers matching a set of dimensions such as the example below.

Finally, we should design which UI is it that will convey the dimensions thus exposed to the recipients. For example, the Program Guide V2 Light, when logged in, could include a switch to also display private dimensions (if any are available to the users) and it could then be used to filter the view and export.

### Example

For Ropecon 2025 volunteers with these dimensions

```yaml
state: accepted
job-category: photographer
```

grant a CBAC entry with the following claims

```yaml
event: ropecon2025
app: program
dimension: photo-permission
```

with validity until 3 months after the end of the event.

## Open questions

### The fate of `cachedDimensions`

Should we add the `includePrivate` (and `listFilterOnly`, `detailOnly`) parameter in `cachedDimensions`, too?

The program guide is accessed fairly often, so would prefer to keep fields used by it as fast as possible. In order to check which dimensions should be retained when resolving `cachedDimensions`, one would have to query all dimensions of the event. This speaks against offering filters on `cachedDimensions`: users who are _special_ can always use `dimensions` instead.

Another option would be to have two underlying database fields: `cachedPublicDimensions` and `cachedAllDimensions`, and use `includePrivate` to toggle which is used to resolve `cachedDimensions`. This would double the raw storage needed for `cachedDimensions` in the database; then again, the `description` field is often long enough so that the row exceeds TOAST threshold and becomes eligible for compression, so actual storage expansion might be less than that.