[ Bug]: Forward cookie header in createServerApiClient for oauth2-proxy

Describe the bug When using AUTH_TYPE=OAUTH2PROXY, server-side rendered (SSR) components make internal requests to the Keep backend via createServerApiClient().

Currently, createServerApiClient() forwards only identity headers (x-forwarded-user, x-forwarded-email, x-forwarded-groups, x-forwarded-access-token). In deployments where reverse proxies or sidecars independently authenticate inbound backend requests with session validation, internal server-to-server calls fail with 401 Unauthorized / 302 Redirect because the session cookie header is dropped.

This causes SSR pages like /incidents and /alerts/feed (which preload initial facets using Server Components) to fail during server rendering.

To Reproduce Steps to reproduce the behavior:

1. Configure the app with AUTH_TYPE=OAUTH2PROXY.
2. Load an SSR page that triggers backend calls, such as /incidents or /alerts/feed.
3. Use a deployment where backend authentication relies on the request cookie at a reverse proxy or sidecar layer.
4. Observe that the internal request loses the cookie header and returns 401 Unauthorized or 302 Redirect.

Expected behavior createServerApiClient() should forward the incoming request's cookie header when AUTH_TYPE === AuthType.OAUTH2PROXY, alongside the existing OAuth2-proxy identity headers.

Screenshots

Additional context

• The current implementation also contains leftover debug console.log statements that should be removed as part of the fix.
• Unit tests should cover both identity header forwarding and cookie forwarding behavior.
• SSR pages such as /incidents and /alerts/feed should render successfully in reverse-proxy-authenticated deployments.