Admin URL config: migrate ApiUrl + WebsocketsUrl from env vars to DI BuildParams

Context

Follow-up from PR #5414 (self-hosted server flavour). The admin resolves its API/WebSocket URLs by reading process.env at the composition root:

• packages/app-admin/src/base/resolveApiUrl.ts → resolveApiUrl(), resolveWebsocketUrl() read process.env.WEBINY_ADMIN_API_URL / WEBINY_ADMIN_WS_API_URL / REACT_APP_WEBSOCKET_URL.
• These values are baked by the Admin.ApiUrl / Admin.WebsocketsUrl extensions via the EnvVar mechanism (bundler replaces process.env.X with a literal at build time).

This is confined to the composition root (the rest of the app reads EnvConfig via DI), and it's consistent with the long-standing resolveApiUrl pattern — but it still means process.env reads live in app code, which we'd prefer to avoid.

Goal

Move the admin URL config onto the existing DI BuildParams mechanism (the one FeatureFlags uses via AdminBuildParam → BuildParams.get(key)), so no process.env is read in app code.

Sketch

• Change Admin.ApiUrl + Admin.WebsocketsUrl extensions to emit AdminBuildParam (DI) instead of EnvVar.
• Read values via BuildParams.get(...) (DI) at the composition root, feeding EnvConfig as today.
• Update every current reader of the env vars:
  • resolveApiUrl / resolveGraphqlUrl / resolveWebsocketUrl
  • the appConfig.getKey("API_URL", process.env.WEBINY_ADMIN_API_URL) call sites (graphql-playground, headless-cms api-info, sdk-playground)

Why not in #5414

• It's an admin-URL-config-wide change (ApiUrl too, not just WebSockets) and touches the AWS flavour's readers — bigger blast radius than the server-flavour WS work.
• Doing WS-only would split the pattern (WS via DI, ApiUrl via env) — worse than the current consistent state.

Note on REACT_APP_WEBSOCKET_URL

On AWS this comes from stack output → env (not an extension), so it likely stays env even after this migration, or needs its own handling. Worth deciding during the work.

Related

• PR #5414
• #5429 (server-flavour deploy packaging)