Argo server not setting allow-origin CORS header

### Pre-requisites

- [x] I have double-checked my configuration
- [x] I have tested with the `:latest` image tag (i.e. `quay.io/argoproj/workflow-controller:latest`) and can confirm the issue still exists on `:latest`. If not, I have explained why, **in detail**, in my description below.
- [x] I have searched existing issues and could not find a match for this bug
- [ ] I'd like to contribute the fix myself (see [contributing guide](https://github.com/argoproj/argo-workflows/blob/main/docs/CONTRIBUTING.md))

### What happened? What did you expect to happen?

I'm trying to access the REST API from a different origin, our argo-server is running in docker desktops k8s and my client app is running on localhost. The docs specify that I should be able to pass `--access-control-allow-origin=*` to the argo-server to return the Access Control Allow Origin header.

After passing this arg and making a request from my client the request is still blocked.

Passing the arg through a kustomize patch:

Sending the same request in postman allowed me to inspect the response, and the header is indeed missing, which leads me to believe it's not set for any `/api/` routes.

Response headers:


### Version(s)

v3.5.11, v3.6.2, sha256:3bde740adcb715656fce1344a6e18920eb90776f7ce59073b6054b5c26a42577

### Paste a minimal workflow that reproduces the issue. We must be able to run the workflow; don't enter a workflow that uses private images.

```YAML
Not related
```

### Logs from the workflow controller

```text
Not related
```

### Logs from in your workflow's wait container

```text
Not related
```

Start at the argo-server entry point that handles the --access-control-allow-origin option and trace requests to the /api routes. Reproduce the missing header with a cross-origin client or Postman, then verify that the configured origin appears in the response headers for those routes.

Written by the indexing model from the issue text.