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.

Commencez par Catalog._load_file_io et suivez les chemins REST _response_to_table et _response_to_staged_table, puis examinez les sites d’appel correspondants de Glue, Hive, SQL, DynamoDB, BigQuery et StaticTable.from_metadata. Vérifiez comment les propriétés des métadonnées sont fusionnées dans la construction de FileIO et ajoutez une couverture montrant que la configuration du catalogue reste la référence pour les paramètres de déploiement sur les chemins concernés.

Rédigé par le modèle d'indexation à partir du texte de l'issue.