Add RBAC permission field and resolver to entity GraphQL nodes

## Background

Each RBAC-managed entity is exposed as a GraphQL node type (e.g. `vfolder_node`, `session_node`, `image_node`, `agent_node`, `keypair_node`, `role_node`, etc.). Today these node types either expose no permission information, or expose legacy/ad-hoc permission fields (e.g. the legacy `permissions` field on `vfolder_node`) that do not reflect the unified RBAC model.

Clients (notably the WebUI) need to know "which operations can the current user perform on THIS entity?" at render time — to gate buttons, menus, and inline actions on a per-row basis. Doing this with separate top-level permission queries forces the client to issue a second round-trip per list view and to re-implement entity-id ↔ permission joining on the client side.

## Goal

Add a uniform `permissions` (or equivalently named) field with a resolver to each RBAC-managed entity GraphQL node type, returning the set of effective operations the current user has on that specific entity instance. The field MUST:

- Reuse the effective-permission computation built under epic BA-5780 (do not re-implement the scope-chain traversal).

- Be batch-safe: list queries (e.g. `vfolder_nodes`, `session_nodes`) MUST resolve permissions in a single batched call per page, not N+1 per row.

- Return a typed enum collection (`OperationType`) rather than free-form strings.

- Behave consistently across REST v2 single-entity GET endpoints if/when those need the same field.

## Scope

1. Define a shared GraphQL field/resolver pattern (helper or mixin) that any entity node can adopt.

2. Apply the field to the v2 entity nodes that are currently RBAC-enforced — at minimum: vfolder, session, image, agent, keypair, role, project, domain, user. Exact list to be finalized per sub-issue.

3. Ensure batched resolution for `\*_nodes` connection queries.

4. Component tests covering: superadmin bypass, project-admin scope, regular user, and unauthorized user (empty set).

5. Replace / deprecate the legacy `vfolder_node.permissions` field once the new field is in place (separate sub-issue, coordinated with WebUI).

## Non-Goals

- Defining new RBAC element types (tracked separately, e.g. BA-5377, BA-5376).

- The top-level effective-permissions resolver itself (tracked under BA-5780 / BA-5797 / BA-5798).

- REST v1 endpoints — v2 only.

## Dependencies

- BA-5780 (epic) — Resolve effective permissions per entity for a given user

- BA-5797 (done) — Repository / service for effective permissions

- BA-5798 — API/SDK/CLI exposure

- BA-5521 — Static permission matrix

- BA-5776 — Scope chain CTE

## Open Questions

- Field name: `permissions` vs `effective_permissions` vs `allowed_operations`. Prefer one that does not collide with the legacy `vfolder_node.permissions`.

- Whether to expose only granted operations, or the full operation list with a boolean per item.

- Caching strategy for high-fan-out list views (per-request cache vs request-scoped DataLoader).

## Sub-issues

To be filed as this epic is broken down — one per entity node (or grouped where it makes sense), plus the shared pattern issue and the legacy-field deprecation issue.

JIRA Issue: BA-5839

Start at the v2 GraphQL entity node definitions for vfolder, session, image, agent, keypair, role, project, domain, and user, then read the BA-5780/BA-5797 effective-permission entry points. Done means a shared typed OperationType field is batch-safe for connection queries and component tests cover superadmin, project-admin, regular, and unauthorized users.

Written by the indexing model from the issue text.