Add ETag conditional requests to the REST transport

Every REST request was issued unconditionally: the ETag returned by the
GitHub API was never stored or replayed, so repeated tool calls that read
the same resource (for example pull request reads, file and commit
listings, and reviews) re-downloaded the full response each time.

This adds an ETagTransport round tripper that caches the ETag and body of
cacheable GET responses and sends If-None-Match on the next identical
request. When the API answers 304 Not Modified, the cached body is served
instead of re-downloading it. The transport is inserted below the
user-agent and auth layers in createGitHubClients(), so cached entries are
scoped by the request's Authorization header and never shared across
tokens. The cache is bounded (LRU) and safe for concurrent use.

Every request is still sent to the server, so responses are always
revalidated and never served stale. Per the GitHub REST API docs, a 304
Not Modified response does not count against the token's primary rate
limit, so repeated reads conserve rate-limit budget and bandwidth while
returning identical data. Rate-limit headers are surfaced from the live
304 response so downstream rate-limit accounting stays correct.

Closes #3025

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 4959e1f9-f8e6-4e97-a487-f395a0123c79