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.

Bắt đầu tại Catalog._load_file_io và lần theo các đường dẫn REST _response_to_table và _response_to_staged_table, sau đó kiểm tra các điểm gọi tương ứng của Glue, Hive, SQL, DynamoDB, BigQuery và StaticTable.from_metadata. Xác minh cách các thuộc tính siêu dữ liệu được hợp nhất vào việc xây dựng FileIO và bổ sung độ bao phủ cho thấy cấu hình catalog vẫn là nguồn có thẩm quyền đối với các thiết lập deployment trên các đường dẫn bị ảnh hưởng.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.