[docs] Add REST management OpenAPI

[JingsongLi]

Purpose

Add an experimental OpenAPI 3.1 contract and documentation for REST permission and table data-policy management. This is the third change in the split series following #9393 and #9400.

Changes

• add rest-management-open-api.yaml with six permission and policy operations
• define structured resources, access values, column allowlists/denylists, expiry semantics, row filters, and column masks
• use strict policy creation and POST .../policies/drop for body-bearing policy removal
• keep authentication deployment-specific instead of requiring Bearer authentication
• validate the catalog and management OpenAPI contracts through one shared validation script
• document resource identity, lifecycle behavior, composition rules, pagination, and failure semantics
• add the management contract to the REST documentation navigation

Scope

This PR contains only the language-neutral REST contract and its documentation. The test REST server implementation and Spark SQL procedures will follow in the next PR.

Tests

• yarn --cwd docs test:rest-openapi
• yarn --cwd docs build

[plusplusjiajia]

format: date-time is wider than what the implementation takes: PermissionAssignment.validateExpireTime requires instant.getNano() % 1_000_000 == 0, so a generated or non-Java client sending 2027-01-01T00:00:00.123456Z produces an OpenAPI-valid grant that the Java implementation rejects. Could this be constrained to the Z form with at most three fractional digits, and reused for the listed assignment so both directions agree?

[JingsongLi]

Fixed in 75e1a415ed. Both GrantPermissionRequest.expireTime and PermissionAssignment.expireTime now reference a shared ExpireTime schema constrained to UTC Z with zero to three fractional digits. The validator covers accepted second/millisecond forms and rejects microseconds and offset timestamps; the REST management documentation now states the same wire rule.

[plusplusjiajia]

These const properties have no type: string. rest-catalog-open-api.yaml declares them the other way — action: { type: string, const: "setOption" } — and the difference bites here because the branches are otherwise identical: CatalogResource/CatalogAllResource, DatabaseResource/DatabaseAllResource, and TableResource/ColumnResource differ only by the constant. A generator that keys off type then sees an ambiguous oneOf and reports multiple matches for valid JSON, so a generated PermissionResource model can't deserialize.
Same pattern in 11 places — the eight PermissionResource branches plus RowFilterPolicyIdentity, ColumnMaskPolicyIdentity, and TablePolicyResource. Worth matching the catalog contract with type: string, or a single-value enum?

[JingsongLi]

Fixed in 904e19056a. All eight PermissionResource branches, both policy identity branches, and TablePolicyResource now declare type: string alongside their single-value const; the internal COLUMN assignment condition was aligned as well. The contract validator now checks every public discriminator name and constant explicitly, so the oneOf branches remain generator-distinguishable.

[plusplusjiajia]

LGTM +1