X-authentik-name can contain non-ASCII characters, causing WebSocket handshake failures in strict ASGI servers

### Describe the bug

## Summary
Authentik forwards user attributes to proxied applications via HTTP headers like `X-authentik-name`. When a user's display name contains non-ASCII characters (e.g. `Céline`, `François`), Authentik sends the raw bytes in the header value.

HTTP/1.1 (RFC 7230 / RFC 9110) recommends that header field values be limited to US-ASCII. Some strict ASGI/WebSocket servers then fail to handle these headers, causing the WebSocket handshake to abort.

### How to reproduce

- Configure an Authentik provider with a reverse proxy (e.g. nginx).
- Have a user whose display name contains a non-ASCII character, such as `Céline`.
- The proxy forwards `X-authentik-name: Céline` to a Streamlit app served by uvicorn 0.51.0 + websockets 16.1.
- The WebSocket upgrade fails with:

### Expected behavior

## Suggested fixes
1. **Option to percent-encode header values** before sending them to the upstream application (so the header stays ASCII-safe).

### Screenshots

_No response_

### Additional context

_No response_

### Deployment Method

Kubernetes

### Version

2026.5.3

### Relevant log output

```shell

```