Verify Dataset Access

Read which principals CURRENTLY hold a dataset's catalog role.

The read-back counterpart to grant/revoke. Polaris is one of the two ways a client actually reads data (the customer's own query engine talks to it directly with vended credentials), so a status view that only verifies S3 describes half the access surface.

The SKU comes entirely from the request and the catalog role name is derived here via the same _dataset_catalog_role the grant path uses, so callers never need to know the naming convention, and can't drift from it.

Unlike the S3 bucket policy, where one read covers every client, Polaris exposes attachment per principal role, so this is one call per principal. They run SEQUENTIALLY on purpose: PolarisClient lazily caches its OAuth token in mutable instance state with a check-then-set, so fanning out concurrently would race on token refresh. Correctness matters more than latency in a feature whose whole job is to be trustworthy; the cap on principal_names bounds the cost.

read_ok=False is a 200 with empty lists, not an error, for the same reason as the bucket-access verify: the caller must render it as "unknown" rather than falling back to what it intended.