(console) Unbounded per-row API fan-out in the Access Control tab causes net::ERR_INSUFFICIENT_RESOURCES

# Setup
- 3 catalogs
- 500 namespaces per catalog (nesting depth 1)
- 3 catalog roles per namespace
- 6 grants per catalog role
- 2000 principals
- 2000 principal roles (1 per principal)

# Issue
The tabs derive row details with one API call per entity and nothing bounds the
entity count. Two distinct problems with the same root cause.

## 1. (tabs - Principals, Principal Roles, Catalog Roles) Unbounded concurrent fan-out

These tabs render every row from the list response (no pagination or
virtualization), and each row mounts a cell component owning its own
`useQuery`:

All of these fire in the same tick, so Chrome (and other browsers)
intermittently fail a subset with `(failed) net::ERR_INSUFFICIENT_RESOURCES`.
`retry: 1` on these queries (and as the global default in app.tsx:47) retries
each failure, roughly doubling the peak.

Among these the 'Catalog Roles' tab takes the biggest hit with the above setup.
https://github.com/apache/polaris-tools/blob/36090e045b9281d8ae837e50b36018bb9913be8a/console/src/components/users/CatalogRolesTab.tsx#L524-L535

## 2. (tab - Privileges) Sequential fan-out

The tab awaits `listGrants` inside a `for...of` loop, so all 4500 grant calls
run *serially* inside the queryFn before a single row renders. No resource
exhaustion here — just 4500 sequential round trips of load time.

https://github.com/apache/polaris-tools/blob/36090e045b9281d8ae837e50b36018bb9913be8a/console/src/components/users/PrivilegesTab.tsx#L218-L228

This is purely a scaling issue, the catalog's management APIs has no bulk
endpoint for any of these, and no server-side
[pagination](https://github.com/apache/polaris/issues/779) either — there is no
`pageToken` / `pageSize` on any path in spec/polaris-management-service.yml.

# Proposal

Client side pagination for the three row-fan-out tabs. Since the API has no
server side pagination, the initial list call stays as is (which also keeps
first-column search working over the full set), but only `` rows are
rendered, which caps concurrent detail calls at the page size. React Query
dedupes by query key, so revisited pages are served from cache.

Virtual lists would also work and avoid the paging UX, but add a dependency.
Pagination feels free in this context.

Privileges needs a separate fix — pagination does not help there, because the
grant calls happen in the queryFn before rendering.

Options to consider -
- fetch grants lazily per visible row (matching the other tabs, so pagination
then bounds it too), or,
- bound concurrency in the existing loop (this can be re used for https://github.com/apache/polaris-tools/issues/191)

Start with console/src/components/users/CatalogRolesTab.tsx lines 524-535 and console/src/components/users/PrivilegesTab.tsx lines 218-228, then inspect the corresponding Principals and Principal Roles tabs and their useQuery calls. Reproduce the large-row setup and observe the browser requests. Done means detail requests are bounded for the row-fan-out tabs and the Privileges tab no longer performs thousands of unbounded sequential grant calls.

Written by the indexing model from the issue text.