App Service: Wake-from-idle env fix

When an App Service app scales down after a period of inactivity, its container is removed and recreated on the next request. The wake path used a stale code path to populate environment variables on the new container, resulting in an empty configuration set being injected. Apps that read configuration at startup would crash or behave incorrectly after their first wake cycle, even if they ran correctly immediately after deploy.

Affected customers were limited to those who had both automatic idle-shutdown enabled and apps that depend on environment variables for normal operation. Apps without environment dependencies, or apps with idle-shutdown disabled, were not affected. No data was lost, no configuration was changed, and there was no security impact. Persistent volumes and stored content were unaffected.

The wake path was updated to read environment variables from the same authoritative source used at deploy time, ensuring the recreated container always receives the current configuration set. The fix was rolled out to production and verified end-to-end against a test app that exercises a full scale-down to wake cycle. All existing customer apps benefit from the fix automatically — no redeploy or customer action is required.

Our end-to-end test suite was extended to cover the full scale-down to wake-up cycle, asserting that environment variables are present in the recreated container. The reconciliation worker that runs every five minutes already detects state drift between the database and running containers, providing an additional layer of detection for any future regressions.