Table properties override catalog configuration when constructing FileIO

从 Catalog._load_file_io 开始，跟踪 REST 的 _response_to_table 和 _response_to_staged_table 路径，然后检查 Glue、Hive、SQL、DynamoDB、BigQuery 和 StaticTable.from_metadata 对应的调用点。验证元数据属性如何合并到 FileIO 构造中，并添加覆盖测试，表明在所有受影响的路径上，catalog 配置对于 deployment 设置仍具有权威性。

When a table is loaded, its metadata properties are merged into the property map used to construct the table's FileIO, and they take precedence over the operator's catalog configuration.

Catalog._load_file_io computes:

load_file_io({**self.properties, **properties}, location)

where properties is metadata.properties. Because table properties come last, a value stored in a table overrides the same key configured on the catalog. The REST path does the same at _response_to_table / _response_to_staged_table, and Glue, Hive, SQL, DynamoDB, BigQuery and StaticTable.from_metadata all funnel table metadata into FileIO construction the same way — 12 call sites in total.

The keys this reaches include implementation selection (py-io-impl, s3.retry-strategy-impl) and transport configuration (s3.endpoint, s3.proxy-uri, s3.signer / s3.signer.uri, gcs.service.host, hf.endpoint, the ADLS storage authorities). These are deployment concerns — an operator sets them on the catalog — but any principal who can commit to a table can currently override them for everyone who reads it.

Issue investigation generated via claude, reviewed by Sung, Kevin, Fokko.