Potential follow-up steps for freshness-aware table loading in REST catalog

### Feature Request / Improvement

- Update docs with new configs for table cache.
There is no page currently for REST catalog configs, probably create a dedicated one under [Catalog properties](https://iceberg.apache.org/docs/latest/configuration/#catalog-properties).
- Freshness-aware lazy snapshot loading
Metadata tables could benefit from this when catalog is in `REFS` mode. `TableMetadata.snapshotSupplier` should go through and update `RESTSessionCatalog.tableCache`
- Freshness-aware loading in `RESTTableOperations`
refresh() and commit() could also do freshness-aware loading and update the table cache. However, the implementation might not be trivial. One potential way to do this is to pass a callback to the ops from `RESTSessionCatalog` that's to be run after loadTable or updateTable communication and can keep the table cache up to date.
Note, for updateTable there are no creds and configs so that part couldn't be updated.
Note, in order to update creds and configs in refresh(), we have to update FileIO that is final atm.
- Expose table cache metrics for observability
We can have an on-demand API that returns `cacheMetricsReport`. Also we can consider sending such through the catalog's metrics reporter (maybe this is too much after each loadTable)
- Credential lifetime check
Before we update the table cache we can check if the credential lifetime was provided in the LoadTableResponse. If yes, and the expiration is "close" (could be configurable) then we can decide not to add the table to cache.

### Query engine

None

### Willingness to contribute

- [x] I can contribute this improvement/feature independently
- [ ] I would be willing to contribute this improvement/feature with guidance from the Iceberg community
- [ ] I cannot contribute this improvement/feature at this time