PROJECT_ADMIN_PAGE permission cannot be assigned to custom project-scoped roles

**Symptom**

In WebUI, the PROJECT_ADMIN_PAGE permission cannot be added to a custom project-scoped role.

**Verified in the backend codebase**

The RBAC permission matrix consumed by the client is exposed through two GraphQL queries. For a project-scoped role to allow PROJECT_ADMIN_PAGE, the entity must appear in both. Only one of them currently exposes it:

- `rbacScopeEntityCombinations` (from VALID_SCOPE_ENTITY_COMBINATIONS in common/data/permission/scope_entity_combinations.py) DOES include PROJECT_ADMIN_PAGE under the PROJECT scope.
- `rbacEntityOperationCombinations` (built from RBAC_ACTION_REGISTRY in manager/actions/action/__init__.py) does NOT include any project_admin_page (nor domain_admin_page) action, so it returns zero assignable operations for the entity. Even though PROJECT_ADMIN_PAGE is a valid entity for the PROJECT scope, no operation (e.g. read) is offered, which makes assignment impossible.

**Inconsistency**

The default project-admin system role hardcodes PROJECT_ADMIN_PAGE: {READ} in GroupData.entity_operations() (manager/data/group/types.py). System roles therefore carry this permission, while custom project-scoped roles cannot obtain it through the client.

**Note**

The WebUI-side rbacPermissionMatrix lives in the backend.ai-webui repository. Whether the final trigger is purely the backend entity-operation gap or a WebUI-side hardcoded list depends on how the client composes these two queries.

JIRA Issue: BA-6843

Start with common/data/permission/scope_entity_combinations.py and manager/actions/action/__init__.py, then compare the two GraphQL permission-matrix queries. Check manager/data/group/types.py for the system-role reference and trace how the WebUI combines the results. Done means a custom project-scoped role can assign PROJECT_ADMIN_PAGE consistently with the default project-admin role.

Written by the indexing model from the issue text.