fix: Scope cached http(s) agents per-destination

[davidkna-sap]

Closes https://github.com/SAP/ai-sdk-js-backlog/issues/604.

[InjunPark-sap]

[Nit] destination.certificates and options already overlap — the same cert material ends up in the hash twice. Is there any functional impact on this change?

[InjunPark-sap]

Including the full destination busts the cache on every token refresh for OAuth2ClientCredentials/OAuth2SAMLBearerFlow destinations — `authTokens.value changes hourly but is never read by createAgent, so keep-alive reuse breaks entirely for those destinations.

[InjunPark-sap]

I would like to suggest scoping the key to only what affects agent behavior:

  const cacheKey = hashCacheKey({
    protocol,
    options,
    proxyConfiguration: destination.proxyConfiguration,
    cloudConnectorLocationId: destination.cloudConnectorLocationId
  });

[davidkna-sap]

I think a 1h cache is acceptable for this use-case. In addition to cloudConnectorLocationId for the proxy the agent also needs to be keyed per-user.

[InjunPark-sap]

nit question and suggest changes on http-agent.ts:309

[InjunPark-sap]

Two open questions:

1. Does authTokens actually appear in the destination object passed to getAgentConfig in OAuth2 flows? If yes, every token refresh produces a new cache key and keep-alive reuse is lost.

2. Is proxyConfiguration sufficient for per-user keying, or are there cases where the user identity affects agent behavior outside of proxyConfiguration.headers?

[davidkna-sap]

@InjunPark-sap

1. I would say that is acceptable.
2. The user keying appears to work for the specific support cases, but in general other destination types appear to be less picky.

[InjunPark-sap]

Approval with the understanding that OAuth2 destinations will see reduced agent reuse on token refresh. (Worth revisiting if it shows up as a connection overhead issue in production.)