[FEATURE] Support trusted delegated authorization for Trino using Gravitino RBAC

### Describe the feature

I would like to propose an official Gravitino integration path for enforcing Gravitino RBAC from Trino's authenticated session identity, especially for BI/JDBC/ODBC deployments.

Gravitino already has Trino connector authentication and session forwarding support, including `gravitino.client.session.forwardUser=true` for simple auth. That is useful, but it still leaves an important deployment gap:

- Trino is often the system that authenticates end users, for example through password, OAuth2, LDAP, Kerberos, or an enterprise gateway.
- BI tools such as PowerBI, Superset, Looker, JDBC, or ODBC clients may not be able to forward a Gravitino-audience OAuth token reliably to Gravitino.
- In those deployments, the trusted identity boundary is Trino's authenticated `Identity`, not a user name or token self-reported by the downstream client.
- Gravitino RBAC should still be the policy source for metadata objects, instead of maintaining a second policy system only in Trino.

### Motivation

For a multi-user Trino deployment backed by Gravitino, a common desired flow is:

```text
BI/JDBC/ODBC user -> Trino authentication -> Trino Identity -> Gravitino RBAC authorization -> query allowed/denied
```

The security property we need is: the user name sent to Gravitino for an authorization decision must be derived from Trino's authenticated session identity and accepted only from a trusted Trino service principal.

Forwarding a user token to Gravitino is not always practical because some BI/ODBC clients cannot provide a suitable Gravitino-audience OAuth token. Forwarding only a client-supplied user name is also not sufficient unless Trino has already authenticated and bound that name to the session identity.

### Describe the solution

A possible upstream-friendly design could include the following pieces:

1. A Gravitino-side delegated authorization API, for example:

```text
POST /api/metalakes/{metalake}/authorize
```

The request would contain the target end user, metadata object, privilege, and optional audit context such as Trino query ID. The endpoint should only accept requests from configured trusted service principals, such as a Trino coordinator service account.

2. A documented Trino integration using Trino's `SystemAccessControl` SPI.

Trino's SPI already provides hooks such as `checkCanSelectFromColumns`, `checkCanInsertIntoTable`, `checkCanCreateTable`, `checkCanDropTable`, `checkCanDeleteFromTable`, and `checkCanUpdateTableColumns`. A Gravitino-provided or documented SystemAccessControl plugin could translate those checks into Gravitino metadata objects and privileges such as `USE_CATALOG`, `USE_SCHEMA`, `SELECT_TABLE`, `MODIFY_TABLE`, `CREATE_TABLE`, `CREATE_VIEW`, etc.

3. A clear separation between service authentication and end-user authorization.

The Trino service authenticates to Gravitino using a service credential. The end user is not authenticated to Gravitino by presenting a token directly; instead, Gravitino authorizes the end user only because the request comes from a trusted Trino principal and Trino has already authenticated the session user.

4. Security requirements documented explicitly:

- Trino must enable real user authentication; anonymous/shared-user deployments cannot provide per-user RBAC.
- Trino must prevent user spoofing through user mapping / impersonation controls.
- Gravitino should fail closed if the delegated authorization request cannot be validated.
- The Gravitino audit log should record both the trusted caller and delegated end user.

### Alternatives considered

- **Only use connector session forwarding**: useful when Trino can forward a suitable user identity or token to Gravitino, but it does not fully address BI/ODBC deployments where Gravitino-audience user tokens are unavailable.
- **Require BI clients to forward OAuth tokens to Gravitino**: not always practical and couples BI client capabilities to Gravitino authentication details.
- **Maintain policies only in Trino**: works technically through Trino access control, but duplicates Gravitino RBAC and risks policy drift.
- **Trust a user name directly from the client**: unsafe unless Trino authenticates and binds that user name first.

### Additional context

Related work:

- #10003 added Gravitino server authentication support for the Trino connector.
- #10559 and #10730 added session user forwarding for the Gravitino Trino connector.

This proposal is narrower than a generic token translation service. It focuses on the case where Trino is the trusted query engine and Gravitino remains the central RBAC policy decision point for metadata objects.

Start with Trino's SystemAccessControl SPI and the hooks named in the issue, then review related work in #10003, #10559, and #10730. Define the delegated authorization API, the Trino-to-Gravitino privilege mapping, trusted service authentication, identity-binding safeguards, fail-closed behavior, and audit requirements; done requires an agreed design and implementation scope.

Written by the indexing model from the issue text.