[rest] Add view penetration endpoint for table access via view

[JingsongLi]

Summary

• Add POST /v1/{prefix}/databases/{db}/tables/{table}/via/{via_db}/{via_object} REST endpoint for view penetration
• If the caller has permission on a view, they can access the underlying table referenced by that view
• Add getTableVia(Identifier table, Identifier via) default method to Catalog interface (defaults to getTable(table))
• Override in RESTCatalog to call the new REST endpoint, and delegate in DelegateCatalog
• Mirror the same implementation in Python (Catalog, RESTCatalog, RESTApi, ResourcePaths)
• This API can only be called by trusted engines; the server must authenticate whether the caller is a trusted engine

Test plan

• Java: testGetTableVia, testGetTableViaWhenTableNotExist, testGetTableViaWhenTableNoPermission
• Python: test_get_table_via, test_get_table_via_with_string_identifier, test_get_table_via_not_exist
• CI tests pass

🤖 Generated with Claude Code

[leaves12138]

Thanks for adding this endpoint. Two things should be addressed before merge:

1. DelegateCatalog#getTableVia delegates directly to wrapped.getTableVia(...). For wrappers like PrivilegedCatalog, this may bypass the getTable wrapping that returns PrivilegedFileStoreTable. Please override getTableVia there, or make the default path preserve the same privilege wrapping.
2. Please update docs/static/rest-catalog-open-api.yaml for the new /via/{viaDatabase}/{viaView} endpoint.

[JingsongLi]

I think getTableVia loses the via authorization semantics after the table is returned.

At PrivilegedCatalog.java:162-166, the wrapped table returned by wrapped.getTableVia(table, via) is re-wrapped with identifier = table. Later read methods in PrivilegedFileStoreTable check that identifier (newSnapshotReader, statistics, store, scans/reads through the privileged store, etc.). So a user who is allowed to select the view via, but not the base table table, can pass getTableVia(...) and then still fail when trying to read the returned table.

For view penetration, the read path probably needs to preserve the via authorization context after getTableVia succeeds. Write/insert paths should still be handled carefully so selecting through a view does not grant write permission to the base table.

[JingsongLi]

Considering the acquisition of tokens, I feel that using identifiers like system tables may be a simpler approach..