feat(rest): load table credentials from the LoadCredentials endpoint

[plusplusjiajia]

Stacked on #898 — until that merges, this PR's diff includes it; the commit to review is the last one.

Adds the plumbing for replacing vended storage credentials, deliberately without any policy:

• StorageCredentialRefresher (a callback returning the vended list) and a default-no-op SetCredentialRefresher hook on SupportsStorageCredentials.
• LoadCredentialsResponse and its parsing. storage-credentials is required here per the REST spec, unlike LoadTable where it stays optional: reading a malformed response as "no credentials" would look like a refresh that succeeded and dropped them. Parse errors deliberately do not carry the response body — it contains
  the credentials themselves.
• RestCatalog::MakeCredentialRefresher builds the callback from the LoadCredentials endpoint with the table session, capturing the catalog so the session's owner outlives copied FileIOs. Both paths that cannot build one say so in the log, since the consequence only surfaces much later as credentials expiring mid-job.
• ResolvingFileIO forwards an installed refresher to resolved delegates, rebuilding cached ones on a late install; retired delegates and the outgoing callback destruct outside the lock, per the discipline refactor(io): hand out S3 delegates by shared_ptr and build them off the lock #898 establishes.

Nothing invokes the refresher yet; the policy that does arrives in the final PR of this series (#892).

MakeCredentialRefresher itself has no unit test — HttpClient is concrete, with no seam to fake. It was verified end-to-end against a live credential-vending catalog: endpoint advertised, GET succeeding, response parsing, and IO continuing on the replacements.