Audit: how URLs are resolved across admin and api

Came out of review on #5697. Nothing is known to be broken here; this is a pass to get the whole picture written down in one place so we can say whether the current shape is the one we want.

What is there today

Admin, browser side. Three env vars are baked into the bundle at build time, then read once at the composition root:

var	set by	on
WEBINY_ADMIN_API_URL	<Admin.ApiUrl> via Project/EnvVar	both
WEBINY_ADMIN_WS_API_URL	<Admin.WebsocketsUrl> via Project/EnvVar	self-hosted
REACT_APP_WEBSOCKET_URL	SetAdminEnvVars from API stack output	AWS

resolveApiUrl.ts turns those into apiUrl / graphqlApiUrl / websocketUrl, which createRootContainer seeds EnvConfig with. Everything downstream injects EnvConfig and reads them off it: WebinySdk, MainGraphQLClient, RetryGraphQLClient, WcpService, ErrorOverlayNetworkErrorHandler, NewsletterSubscriptionService.

Two things write those env vars at watch time instead of taking the config value:

• SetAdminEnvVars (AWS) overwrites WEBINY_ADMIN_API_URL with the API Gateway URL from stack output.
• prepareDevServerSession (self-hosted) overwrites both admin URLs with /api when the dev proxy is on.

Api side. <Infra.ApiUrl> emits the WEBINY_API_URL build param. Read by FileManagerServerConfig for the upload endpoint and by SettingsInstaller for the initial file srcPrefix. File URLs themselves do not use it: FileUrlGenerator is srcPrefix + file.key, and srcPrefix is persisted, editable settings. On AWS the origin comes from the ServiceDiscovery manifest's CloudFront domain instead.

Things worth a look while we are in here

1. Two sites bypass EnvConfig and read process.env themselves. app-sdk-playground/src/plugins/useCodeExecution.ts:23 reads WEBINY_ADMIN_API_URL raw. self-hosted-auth/src/admin/Extension.tsx had its own copy of the rules until #5697; it now shares the resolver, but the pattern says the seam is easy to miss. Should reading a URL outside EnvConfig be possible at all?

2. Relative vs absolute is inconsistent. resolveApiUrl resolves to absolute against the page origin so one build runs anywhere. The sdk-playground path would get the raw /api. Worth settling which form is canonical.

3. Three ways to set the same thing. Config extension, watch-time env overwrite, and stack output. The precedence is only written down in comments, and the dev proxy has to overwrite rather than fill blanks because the config already ran. See also #5703, which is the api-side version of the same tension.

4. srcPrefix is a fourth mechanism. Persisted, user-editable, seeded once at install. Not obviously wrong, but it means the file URL answer does not come from the same place as everything else.

Not asking for a change

Just a pass, and a decision on whether 1 and 2 are worth tidying.