4. Expose Permission field across permission API (DTO / GraphQL / REST v2)

## Background

Expose the new Permission bitmask field across the permission-related API surface, in parallel with the existing operation-based field during the transition.

## Scope

- Add the Permission field to the relevant v2 DTOs (common/dto/manager/v2/...), Strawberry GraphQL types (api/gql/...), and REST v2 responses/requests for the permission/role entities.
- Keep the existing operation-based field available in parallel during the transition.

## Out of Scope

- Removing operation-based fields (follow-up story).

## Depends On

Story: add Permission bitmask column (column must exist). Recommended after the resolution switch story.

## Success Criteria

- Permission field is present in API responses (and accepted on requests where applicable) for the permission/role entities.
- existing operation-based API behavior unchanged.
- pants lint/check/test pass for affected packages.

JIRA Issue: BA-6351

Start by inspecting the permission and role entities under common/dto/manager/v2/..., api/gql/..., and the REST v2 implementation to identify the relevant request and response types. Check the dependency that adds the Permission bitmask column, then run pants lint/check/test for the affected packages; done means the field is exposed or accepted where applicable while operation-based behavior remains unchanged.

Written by the indexing model from the issue text.