[#10685] feat(iceberg-rest): Support vended credentials on planTableScan endpoint

[sachinnn99]

What changes were proposed in this pull request?

Add X-Iceberg-Access-Delegation header support to the planTableScan endpoint and return storage credentials in the response when vended-credentials is requested. Mirrors the existing credential-vending flow from createTable/loadTable/registerTable (#10684).

Changes:

• IcebergTableOperations.planTableScan: add @HeaderParam(X_ICEBERG_ACCESS_DELEGATION), compute isCredentialVending, build the 3-arg IcebergRequestContext, merge storage-credentials into the response JSON when eligible
• IcebergTableOperations: inject IcebergCatalogWrapperManager (same pattern as IcebergConfigOperations) and add a private buildScanResponseWithCredentials helper that serializes the response to an ObjectNode and appends the storage-credentials array
• CatalogWrapperForREST: add getCredentialsIfEligible(identifier, requestCredential, privilege) that wraps shouldGenerateCredential + getCredential and returns credentials separately, reusing the same Gravitino→Iceberg credential conversion pattern as getTableCredentials
• MockIcebergTableOperations: update constructor to match the parent
• TestIcebergTableOperations: add three tests — testPlanTableScanWithCredentialVending (no header / local / S3), testPlanTableScanRemoteSigningNotSupported, testPlanTableScanInvalidAccessDelegation

Note: PlanTableScanResponse in Iceberg 1.10.1 has no config/credentials field (credentials support was added in Iceberg PR #14518, targeting 1.11.0+). Credentials are therefore merged into the response JSON at the endpoint. When Gravitino upgrades to Iceberg 1.11.0+, the JSON-level merge can be replaced with a direct PlanTableScanResponse.Builder.withCredentials(...) call in CatalogWrapperForREST.planTableScan. Credential eligibility (shouldGenerateCredential) is still enforced at the wrapper level so local/HDFS tables correctly receive no credentials.

Why are the changes needed?

The Iceberg REST spec defines X-Iceberg-Access-Delegation as a valid header on planTableScan and CompletedPlanningResult includes a storage-credentials field. Currently, clients performing server-side scan planning must make a separate GET .../credentials call to obtain storage access credentials before reading the data files returned in the scan plan.

Fix: #10685

Does this PR introduce any user-facing change?

Yes. The planTableScan REST endpoint now accepts the X-Iceberg-Access-Delegation header and returns vended credentials in the response storage-credentials field when requested. Backward compatible — clients that do not send the header get existing behavior.

How was this patch tested?

Added unit tests in TestIcebergTableOperations:

• testPlanTableScanWithCredentialVending — no vending without header, no vending for file:// location, vending present for s3:// location with expected DUMMY_CREDENTIAL_TYPE
• testPlanTableScanRemoteSigningNotSupported — 406 response for remote-signing
• testPlanTableScanInvalidAccessDelegation — 400 response for invalid header values

All existing TestIcebergTableOperations tests still pass (no regressions).