Audit Log displays Entra `sub` instead of identifiable user for OBO-authenticated MCP calls

## Summary

When an Entra-authenticated client accesses an OBO-capable MCP server through AI Gateway, the Gateway Audit Log displays the JWT `sub` claim in the **USER** field rather than a human-readable or stable Entra user identity.

For example, an audit entry for a request made by `user@example.com` is displayed as:

```text
USER:
```

I confirmed that this value is exactly the `sub` claim from the Entra access token.

The same token contains both the user's UPN and Entra Object ID, so Gateway has sufficient information to record an identifiable user.

## Environment

* AI Gateway: QA
* Gateway version: `1.29.0`
* Authentication: Microsoft Entra ID
* Flow: delegated user authentication / OBO
* Target: MCP server supporting OBO
* MCP operation observed: `tools/call`

## Steps to reproduce

1. Configure an MCP server behind AI Gateway with Entra OBO authentication.
2. Authenticate to Gateway using an Entra delegated user token.
3. Invoke an MCP operation, e.g. `tools/call`.
4. Open **AI Gateway → Audit**.
5. Locate the corresponding request.
6. Inspect the value shown in the **USER** column.
7. Decode the Entra access token used for the request and compare its identity claims.

## Actual behavior

Gateway displays an opaque value in the Audit Log **USER** field:

```text

```

Decoded token claims confirm that this is the JWT `sub`:

```text
sub =
oid =
upn = user@example.com
name = Example User
scp = access_as_user
```

Therefore, the value shown as **USER** is currently sourced from `sub`.

## Expected behavior

The Audit Log should identify the originating Entra user in a way that is meaningful to an administrator.

For example:

```text
USER: user@example.com
```

For durable identity and audit correlation, Gateway should also retain the Entra identity using:

```text
oid + tid
```

The `sub` claim may still be useful for protocol-level correlation and could remain available in the event details, but it should not be the only identity exposed as the human-facing **USER** value.

Suggested mapping:

```text
Audit USER -> upn / preferred_username
Canonical user ID -> oid + tid
Event details -> sub, oid, tid, appid/azp, upn, name
```

## Why this is a problem

`sub` is an opaque, pairwise subject identifier. An administrator reviewing the Audit Log cannot reasonably determine which Entra user performed an action from this value alone.

This makes OBO-originated audit events substantially less useful for:

* security investigations
* user activity tracing
* operational troubleshooting
* audit/compliance review
* correlating Gateway activity with Entra users

This is particularly confusing because other audit entries may appear with human-readable identities such as `user@example.com`, while OBO requests appear under an opaque identifier.

## Evidence

For the reproduced request:

```text
Gateway Audit USER
=

JWT sub
=
```

The values are an exact match.

The same JWT simultaneously contains:

```text
upn = user@example.com
oid =
tid =
```

so the Gateway has access to a recognizable user identity at the point the audit record is created.

Additional token context, sanitized:

```text
iss = https://sts.windows.net//
aud = api://
tid =
appid =
scp = access_as_user
```

## Suggested fix

When generating an audit event for an Entra delegated/OBO request:

1. Use `upn` or `preferred_username` as the human-readable **USER** value when available.
2. Persist `oid` and `tid` as the stable Entra identity.
3. Preserve `sub` separately for token-level correlation.
4. Fall back to `sub` only when no more appropriate user identity claims are available.

If the current use of `sub` is intentional, the Audit UI should at minimum expose the associated `upn`/`oid` and avoid presenting `sub` alone under a field labelled **USER**.

## Severity / impact

Suggested severity: **Medium**

Authentication and authorization appear to function correctly; the issue is specifically with audit identity attribution/presentation. However, it materially reduces the usefulness of the Gateway Audit Log for OBO-authenticated traffic.