Session/ Request/ Auth Context Propagation

### Is your feature request related to a problem or challenge?

We need to pass request context from Datafusion to our Iceberg connector.

Today, the [Datafusion Session](https://github.com/apache/datafusion/blob/6a0e76ed692afaafd616e0d98d51bef63c1ff02d/datafusion/session/src/session.rs#L75) (which is already available for each query) terminates at the Iceberg catalog boundary. Scans for example, use a shared catalog and then [call the `catalog.load_table(&self.table_ident)`](https://github.com/apache/iceberg-rust/blob/22e80a63dbb4e58e034672b4ff665a6eae82fa02/crates/integrations/datafusion/src/table/mod.rs#L135) function on it, which doesn't support any way of context propagation.

Our downstream REST catalog requires this context to make authorization, rate limiting and shard routing decisions.

### Describe the solution you'd like

### SessionCatalog Trait
The Java implementation solves this with a separate [`SessionCatalog`](https://github.com/apache/iceberg/blob/main/api/src/main/java/org/apache/iceberg/catalog/SessionCatalog.java#L34) interface which coexists next to the regular `Catalog` interface.
It replicates all interface methods, but accepts a [`SessionContext`](https://github.com/apache/iceberg/blob/2d3f5c24e0697b361fe95362d8ee13b915e98048/api/src/main/java/org/apache/iceberg/catalog/SessionCatalog.java#L36) for each. Compare the Java [Catalog's](https://github.com/apache/iceberg/blob/2d3f5c24e0697b361fe95362d8ee13b915e98048/api/src/main/java/org/apache/iceberg/catalog/Catalog.java#L326):
```java
Table loadTable(TableIdentifier ident);
```
to the [SessionCatalog's](https://github.com/apache/iceberg/blob/2d3f5c24e0697b361fe95362d8ee13b915e98048/api/src/main/java/org/apache/iceberg/catalog/SessionCatalog.java#L223):
```java
Table loadTable(SessionContext context, TableIdentifier ident);
```

A Rust implementation could re-use this mechanism and provide a separate `SessionCatalog` trait, along with a `SessionContext` struct (which is a simple struct without any behavior). The Datafusion integration's `IcebergTableProvider` could then store an [`Arc` instead](https://github.com/apache/iceberg-rust/blob/22e80a63dbb4e58e034672b4ff665a6eae82fa02/crates/integrations/datafusion/src/table/mod.rs#L71), translate the Datafusion `Session` to an Iceberg `SessionContext` for each query, and pass it along to the Catalog.

### REST Implementation
The RestCatalog then needs to materialize the query context into the HTTP request metadata. For our use case, we really only need to forward the same context that we received, but the full Java implementation allows for authentication handled by the client.

The Java implementation uses the [AuthManager](https://github.com/apache/iceberg/blob/main/core/src/main/java/org/apache/iceberg/rest/auth/AuthManager.java#L33) for this. It is a field of the RestSessionCatalog implementation, and is [called on each catalog method](https://github.com/apache/iceberg/blob/2d3f5c24e0697b361fe95362d8ee13b915e98048/core/src/main/java/org/apache/iceberg/rest/RESTSessionCatalog.java#L336) to produce a "contextual" AuthSession from a SessionContext.
The `AuthSession` is then used by the Rest/ HTTP client to authenticate any request with headers.

Note that this flow doesn't support propagation of arbitrary metadata, but only authentication information supported by the AuthManager/ AuthContext. This still suits our current needs.

---

On my willingness to contribute: I'm happy to handle the implementation, but I need some feedback on the overall design (whether or not we want to follow the Java approach).

### Willingness to contribute

I would be willing to contribute to this feature with guidance from the Iceberg Rust community

Start with datafusion/session/src/session.rs and crates/integrations/datafusion/src/table/mod.rs, then compare the linked Java SessionCatalog, AuthManager, and RESTSessionCatalog implementations. Confirm the design with the community before changing the catalog interfaces; done means request context can reach the catalog and REST HTTP metadata without unresolved API decisions.

Written by the indexing model from the issue text.