Include the authorizing user on dynamic OAuth application names

What does this MR do and why?

Dynamically-registered (DCR, POST /oauth/register) OAuth applications are created anonymously on behalf of MCP clients — there is no authenticated user at registration time. As a result, an admin looking at /admin/applications can see the client name but not which user is actually using a given dynamic application.

This MR records the authorizing user on the application name, without adding any columns to the oauth_applications table.

Changes (app/controllers/oauth/authorizations_controller.rb)

• When a user approves authorization of a dynamic application, append — authorized by @<username> to the application name.
• Approval only: stamping is gated on Doorkeeper's authorization outcome — the name is stamped only when authorize_response is a CodeResponse (an authorization code was issued). A denial or error yields an ErrorResponse, so it is left untouched and we never misattribute an authorization the user did not grant.
• Sanitized: GitLab usernames are already restricted to a safe character set, but the value is defensively stripped of anything outside [A-Za-z0-9_.-] before being persisted into the name (which is rendered in the admin UI).
• Idempotent: applied once — repeat authorizations do not append again.
• Dynamic only: non-dynamic / instance-wide applications are never modified.

Example resulting name: [Unverified Dynamic Application] kiro — authorized by @jessieay

No database changes

The identifying data lives in the existing name column, already surfaced in the Admin UI and REST API. The single-record application.update(name: ...) runs on the already-loaded application record (no bulk update, no new query against a large table).

References

• Resolves Update DCR implementation to capture username f... (#605884)

How to set up and validate locally

1. Register a client via DCR and complete the authorization flow, approving on the consent screen.
2. In Admin → Applications, confirm the app name reads [Unverified Dynamic Application] <client_name> — authorized by @<your-username>.
3. Repeat the authorization — confirm the username is not appended twice.
4. Deny an authorization for a fresh dynamic app — confirm the name is not stamped.

Screenshots or screen recordings

N/A — no UI changes; only the stored application name is affected.