fix: forward incoming auth headers in webpack dev proxy

[mturley]

Description

The webpack dev server captures the kubeconfig token at startup and sets it as a static proxy header via headers: getProxyHeaders(). This overwrites any dynamically forwarded auth headers from a host backend proxy, breaking dev impersonation (e.g. DEV_IMPERSONATE_USER/DEV_IMPERSONATE_PASSWORD).

This PR replaces the static headers approach with an onProxyReq callback that dynamically forwards the Authorization header from each incoming request when present, falling back to the startup-captured token for standalone dev mode.

The same fix was applied to the model-registry UI in kubeflow/hub#2544.

Changes

• Split getProxyHeaders() into:
  • getKubeconfigToken() — captures kubeconfig token at startup (fallback)
  • getProxyHeaders() — returns only static headers (kubeflow-userid for internal auth)
  • onProxyReq — dynamically forwards Authorization and x-forwarded-access-token headers per request
• Proxy config now uses both headers: getProxyHeaders() (static) and onProxyReq (dynamic)

How Has This Been Tested?

Tested manually in the model-registry module (same fix pattern) against an ODH cluster:

1. Started the host backend with DEV_IMPERSONATE_USER and DEV_IMPERSONATE_PASSWORD set
2. Verified the bug: with static headers, the impersonated user's token was overwritten by the startup token
3. Verified the fix: with onProxyReq, the incoming auth header from the host proxy is forwarded correctly

[google-oss-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign paulovmr for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• workspaces/frontend/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[thaorell]

/lgtm

I have tested and the changes work accordingly, @caponetto can you (optionally) offer a secondary review on this?

[thaorell]

/ok-to-test

[caponetto]

Thanks @mturley!

/lgtm

[ederign]

/hold

We are looking with the MR folks to see why they did this in this way.

[mturley]

@ederign the MR PR is merged now, should we unhold this one? Not sure if I missed discussions about the approach. cc @lucferbux