#890 Fix stale auth header accumulation on ConnectRPC retry Pull request opened by jeevb The old gRPC interceptor rebuilt ClientCallDetails from scratch on each attempt, so stale auth headers could never persist across retries. The ConnectRPC interceptor mutates a shared RequestContext via update(), which only adds/overwrites keys but never removes old ones. When the auth header key changes after credential refresh (e.g. "authorization" → "flyte-authorization"), both headers coexist on the retry. The backend's connect headerInterceptor maps both into the "authorization" gRPC metadata key, and if the expired token appears first, auth fails. Fix: track injected auth headers and remove them before reinjecting on retry, restoring the gRPC-era "fresh metadata per attempt" property. flyteorg/flyte-sdk