Authorize 7 AiCatalog GraphQL types for fine-grained tokens

Summary

A fine-grained personal access token is denied the catalog GraphQL types below: they declare no authorize_granular_token directive and are still listed in config/authz/graphql/authorization_todo.txt, so the fields that return them give the token null or an empty list, even when it can read the catalog item. A legacy token can use them.

As agreed in !267273 (comment 4195231927), I will send this domain's types in one merge request, which closes this issue.

Proposal

• read_ai_catalog_item on the user, as their items declare, for the versions of an agent, a flow and a third-party flow: AiCatalogAgentVersion, AiCatalogFlowVersion and AiCatalogThirdPartyFlowVersion. The fourth version type, the skill's, already declares it.
• read_ai_catalog_mcp_server on the user for AiCatalogMcpServer, the ability it already checks for the user.
• read_ai_catalog_item on the user for AiCatalogMcpTool, as the list of built-in tools does.
• Returned only below one of those types or a catalog item, so each declares the permission its parent checks (parent_authorizes: :read_ai_catalog_item), with a spec for each parent: AiCatalogMcpToolIcon, AiFoundationalChatAgentFlowConfig, and AiCatalogItemPermissions, which already relies on its parent and now names the permission.

This adds the Read assignable permission of the existing read_ai_catalog_mcp_server permission, next to the create, update and block ones, so a token that reads catalog items does not also read the MCP servers. It adds no other permission.

Related to #593878.

I found this while working on gitlab-mcp-server.