[rest] Add server-issued view read grants

[leaves12138]

Purpose

Prevent view permission penetration from trusting a client-supplied via identifier. A client can only use a short-lived, tamper-resistant read grant issued after the server authorizes a consistent view version and independently verifies its transitive dependency closure.

This is the core/REST protocol PR split from the discussion in #8112. Engine-specific extraction and propagation of trusted view dependencies can follow separately. Until a trusted server-side analyzer supplies and verifies those dependencies, grant issuance fails closed.

Changes

• Add direct dependencies to View / ViewSchema, persist them in JDBC, and add an atomic UpdateDependencies view change. Values received from REST clients are metadata hints, not authorization evidence; ReadGrantService.ViewResolver#getVerifiedDependencies must return the independently verified dependency list and grant issuance rejects missing or mismatched verification.
• Add Catalog#getViewForRead and POST .../views/{view}/read-grant, which atomically return a view definition and grant after an optimistic full-closure consistency check.
• Add reusable server-side ReadGrantService and HMAC-SHA256 primitives. Grants bind a stable, non-secret authenticated subject, catalog/warehouse audience, stable root-view ID/version, expiry, nonce, and a fixed-size authorization version covering all nested-view versions, dependency edges, and target-table fingerprints. Raw Authorization headers and bearer credentials must never be embedded in claims.
• Accept only canonical Base64URL grant encodings and validate the signature, audience, authenticated subject, expiry, root permission, current authorization version, and requested target on every protected request.
• Support views with multiple direct and nested dependencies. Every leaf table in the verified closure is eligible only through the root grant and receives its own target/path-scoped read-only data credential.
• Detect concurrent dependency or table replacement while issuing storage credentials by validating current metadata immediately before and after provider issuance.
• Replace client-provided read-via headers with the opaque X-Paimon-Read-Grant header. Grants are accepted only by read endpoints and never authorize mutations.
• Renew only by submitting the correctly signed expired grant. The server requires the exact same root view ID, root version, and complete authorization version; any root, nested-view, edge, table fingerprint, or permission change makes renewal terminal and requires a new planning context.
• Make renewal idempotent across independently deserialized contexts and server instances: the old signed nonce and renewal time window produce deterministic renewed claims when the shared secret, audience, and authoritative metadata agree.
• Keep the authorization version in ReadAuthorizationContext, atomically replace the grant and expiry, and retry only a 403 whose resourceType is READ_GRANT, once. Other 403 responses are terminal.
• Require grant-backed reads to use backend-enforced, read-only data credentials bound to the requested logical table and authoritative storage paths. Credentials cannot outlive the grant and use a substantially shorter TTL (30 seconds in the reference server).
• Route grant-backed external tables through token-backed FileIO, reject writes in Paimon and in the reference storage backend, reject paths outside the credential scope, and avoid caching grant-backed table objects.
• Preserve pre-change SnapshotLoaderImpl serialization compatibility and update the REST OpenAPI contract and reference server.

Apache Paimon does not contain a deployable production REST server. The reusable validation and provider contracts are production code in paimon-api; RESTCatalogServer integrates them as the reference implementation used by end-to-end tests. A production server must obtain the authenticated subject and verified dependency graph from its own trusted authentication and query-analysis layers.

Security and revocation model

• A view identifier, arbitrary via value, or client-constructed dependency list grants no access.
• The signed payload is authenticated but not encrypted, so it contains only a stable opaque subject, never reusable credentials.
• Future REST requests re-check the current view permission and complete dependency closure. Permission revocation or metadata replacement therefore takes effect immediately at the REST layer.
• An already issued raw storage credential can remain usable only until its separately bounded short expiry. The reference implementation caps this window at 30 seconds; production deployments choose and enforce their provider TTL.
• Root-view, nested-view, dependency-edge, target identity/schema, audience, subject, or permission changes invalidate the old grant and prevent renewal.

Validation

• mvn -pl paimon-api -Pfast-build -DwildcardSuites=none test (69 tests)
• mvn -pl paimon-core -am -Pfast-build -DfailIfNoTests=false -DwildcardSuites=none -Dtest=MockRESTCatalogTest,CachingCatalogTest,RESTApiJsonTest,SnapshotLoaderImplCompatibilityTest test (189 tests)
• mvn -pl paimon-api,paimon-common,paimon-core -am -DskipTests compile
• Parsed docs/static/rest-catalog-open-api.yaml successfully.