Table properties override catalog configuration when constructing FileIO

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:

```python
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.

Catalog._load_file_io から始めて REST の _response_to_table と _response_to_staged_table のパスを追跡し、続いて Glue、Hive、SQL、DynamoDB、BigQuery、StaticTable.from_metadata の対応する呼び出し箇所を調べます。メタデータプロパティが FileIO の構築にどのようにマージされるかを確認し、影響を受けるパス全体でデプロイ設定に対してカタログ構成が引き続き優先されることを示すテストカバレッジを追加します。

索引モデルが issue の本文から書いたものです。