Core: Rebuild REST cached tables with current context

[manuzhang]

This PR fixes a context-leak risk in REST table caching: after a 304 response, callers now get tables rebuilt with their own current auth/context rather than reusing potentially stale context captured by the original cached supplier.

---

Co-authored-by: @codex

[gaborkaszab]

Hey @manuzhang ,
Thanks for the PR. I started taking a look as the owner of the original code, but frankly I found the code somewhat complicated to understand. So before taking a deeper look, may I ask the motivation and the problem being solved in more details. What is the exact issue, what engine, what use-case, what error, what breaks, etc. Is this a real issue you see in some test/prod environment or a theoretical one that you think might break one time?
The reason I ask is that most of the engines use RESTSessionCatalog through a single RESTCatalog and as a result through the same session (and even many different users share the same session). I've checked Spark, Hive, Impala does this if I haven't missed anything, while Trino creates SessionContexts on its own.
Also, the idea to balance between tables being cached and credentials expiring, the general rule of thumb is to set the expiration on the cache way lower than the expiration of the credentials to guarantee that whenever getting a table from the cache, its creds will live for enough time to finish the query. Isn't this something that helps with you use-case?

[manuzhang]

@gaborkaszab This is an issue exposed by Codex Security Scan, which I manually checked and validated. I get your point that it might not a real issue in the production environment and the fix might be overkill. Let me think more about it.