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

[plusplusjiajia]

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. Loads snapshot the refresher together with the credentials, and installing one bumps the credential generation, so a delegate loaded mid-install is rebuilt rather than cached without it.

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.