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

[plusplusjiajia]

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

• StorageCredentialProvider (a typed source returning the vended list) and InitializeStorageCredentials, which installs the initial credentials and provider before first use. SetStorageCredentials remains for later same-scope updates.
• 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::MakeStorageCredentialProvider builds a provider from the LoadCredentials endpoint with the table session, keeping the REST path and session ownership inside the provider. 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 the installed provider to resolved delegates during credential initialization. Loads snapshot the provider together with the credentials, and credential installs bump the generation, so a delegate loaded from an older set is rebuilt rather than cached.

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

MakeStorageCredentialProvider 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.

[wgtmac]

I pushed a small update that replaces the refresh callback with a typed StorageCredentialProvider::Load() and initializes each FileIO with both initial credentials and the provider before first use; SetStorageCredentials() remains for later same-scope updates. This keeps REST endpoint/auth/query details inside the REST provider, keeps ResolvingFileIO simple, and avoids exposing opaque callback or late-initialization state.

Thanks for adding this and sorry for the long delay!