feat(rest): support freshness-aware table loading

[YuangGao]

Which issue does this PR close?

• Closes RestCatalog: support freshness-aware table loading (If-None-Match / 304 Not Modified), as Iceberg Java does #3340.

What changes are included in this PR?

load_table never sent If-None-Match and parsed a body-less 304 as a 200. Following Java (apache/iceberg#14398):

• Cache tables loaded with an ETag, keyed by session and identifier; a later load sends If-None-Match and returns the cached table on 304.
• Add rest-table-cache.max-entries (default 100, 0 disables) and rest-table-cache.expire-after-write-ms (default 5 minutes).

Only load responses fill the cache, as in Java: the reference server's ETag also covers query parameters, so a create response's never matches a later load.

Are these changes tested?

• Unit tests with mockito.
• Verified against apache/iceberg-rest-fixture:latest: loads return 200 then 304; after a commit, drop or re-create, the stale ETag yields 200 or 404 instead of the cached table.

AI Disclosure

• AI-assisted implementation.

[JeonDaehong]

Compared with Java's RESTTableCache: the property names, defaults, the (session id, identifier) key and the 304 handling all match. One difference: Java rejects rest-table-cache.expire-after-write-ms of 0 (Preconditions.checkArgument(expireAfterWriteMS > 0, "Invalid expire after write: zero or negative")), while here 0 is accepted. Should this reject 0 too, or document what 0 does?

[YuangGao]

good catch, thanks. 0 is now rejected like in Java, since it's ambiguous (disable vs never expire) and max-entries=0 already turns the cache off. while there, also capped it at 1000 years, which moka would otherwise panic on.

[JeonDaehong]

Thanks, the upper bound is a nice catch too.