feat: allow AI Studio websocket clients to register a stable provider name (avoid aistudio-XXXX churn)

[xyonium]

Is a request payload issue?
No.

Problem
AI Studio websocket providers (registered via /v1/ws) always get a random aistudio-XXXX name generated server-side in internal/wsrelay/manager.go (randomProviderName()). Because these runtime-only credentials are also deleted on disconnect (wsOnDisconnected -> AuthUpdateActionDelete), every browser restart produces a brand-new provider entry and the old one disappears:

• Provider / usage statistics are aggregated by Metadata["email"], which is just the random channel ID - so per-account stats are impossible to keep attached to one identity.
• After a restart you cannot tell which new provider corresponds to which Google account, so anomalies cannot be traced back to a specific account.

Proposal
Wire the existing-but-unused wsrelay.Options.ProviderFactory hook so a client can claim a stable name via a provider_name query parameter on the websocket upgrade request, e.g.:

wss://proxy.example.com/v1/ws?auth_token=...&provider_name=user1

With a stable name, the manager's existing "replaced by new connection" path kicks in on reconnect: the old session of the same provider is replaced and wsOnDisconnected skips the registry delete, so the provider entry and its usage statistics survive restarts. Clients that do not send the parameter keep the current random-name behavior (fully backwards compatible).

Naming rule (for traceability): the value is trimmed and lowercased by the manager, and the aistudio- prefix is enforced in the factory because wsOnConnected only registers channels carrying that prefix.

I have a working patch (16 lines in sdk/cliproxy/service_auth.go) and will open a PR against dev referencing this issue.

Use case
Multi-account AI Studio keep-alive setups (e.g. one headless browser per Google account): each browser instance injects its own account identifier as provider_name, so the CLIProxyAPI dashboard shows one stable entry per account.

OS Type

• OS: Linux (Docker)

[luispater]

Thank you for the feedback and proposal. We currently have no plans to make changes or improvements to this part of the codebase, so we are closing this issue as not planned.