[Fix] Dev login breaks in sandboxes when the deployment app env leaks into task processes

[roomote-roomote]

Opened on behalf of Matt Rubens. Follow up by mentioning @openmote, in the web UI, or in Slack.

What changed

Worker sandboxes no longer inject the hosting deployment's app env into user-facing task processes. WorkerEnv.buildUserFacingEnv() previously re-exported the captured APP_ENV/R_APP_ENV (e.g. production on the hosted deployment) into every setup command, PM2-managed dev server, and terminal session, and those values were written as unconditional export lines into ~/.roomote/env.sh. Because every non-interactive bash re-sources that file (the __ROOMOTE_ENV_LOADED guard is unset at the end), nested shells clobbered per-command R_APP_ENV=development overrides, and resolveAppEnv() only reads R_APP_ENV, so .env.local and partial inline overrides could not win. In Roomote-on-Roomote sandboxes this made the web app resolve a production app env and disable /auth/dev-login despite WEB_DEV_LOGIN_ENABLED=true.

The deployment app env now stays worker-internal: workerConfig.appEnv still feeds keepalive defaults, Sentry, and telemetry, but it is never exported to task processes. The legacy ROOMOTE_APP_ENV alias (still injected by the controller for pre-rename snapshot workers) is now scrubbed from the worker process env alongside R_APP_ENV/APP_ENV. The checked-in .roomote/environments/roomote.yaml drops its sed export-guard workaround, which this change makes unnecessary.

Why this change was made

The deployment's app env describes Roomote's own deploy context, not the environment of the user project running inside the sandbox — forwarding it into task processes was a category error that the dev-login route's own comments already anticipated ("a sandbox that inherits a stray app env"). Fixing it at the source removes the need for brittle per-environment-config workarounds that must track the full alias trio.

Impact

Dev login and development app-env defaults work out of the box in dogfood sandboxes without env-config sed hacks; sandbox task processes fall back to the documented development app-env default unless an environment config sets the value explicitly. No behavior change for the worker's own keepalive, monitoring, or telemetry, and no change to production deployments' own app-env handling. Sandboxes resumed from old snapshots self-heal on their next run under the new worker release because ~/.roomote/env.sh is rewritten every run. Deployed environment configs that carry the same sed workaround (e.g. the hosted "Roomote" dogfood environment) can drop it once this ships in a worker release.

How it was tested

• Updated apps/worker/src/env/__tests__/worker-env.test.ts with regression assertions that buildUserFacingEnv() contains none of APP_ENV, R_APP_ENV, or ROOMOTE_APP_ENV, plus scrub coverage for the legacy alias.
• Full @roomote/worker Vitest suite passes (135 files, 1302 tests).
• pnpm lint and pnpm check-types pass across all workspaces.
• No browser proof: the change is worker env-propagation behavior, and the current sandbox was provisioned by the pre-fix worker (with the workaround applied), so a dev-login screenshot here could not honestly demonstrate this change; the regression tests are the authoritative evidence.

Checklist

• The PR title follows the repo convention: [Fix], [Feat], [Improve], [Refactor], [Docs], or [Chore] followed by a user-facing description
• This PR is small and scoped to one change
• pnpm lint and pnpm check-types pass locally
• I added tests or included a clear manual validation note above
• I removed secrets, tokens, private keys, and customer data from code, logs, and screenshots
• If this change should appear in the changelog, I ran pnpm changeset

[roomote-roomote]

No code issues found. See task

Reviewed keeping the deployment app env worker-internal: buildUserFacingEnv() no longer exports APP_ENV/R_APP_ENV, the legacy ROOMOTE_APP_ENV alias is scrubbed from the worker process env, and .roomote/environments/roomote.yaml drops the now-unnecessary sed guard. Confirmed the controller injects R_APP_ENV alongside ROOMOTE_APP_ENV (packages/compute-providers/src/worker-env/base.ts), so appEnv resolution stays correct without a ROOMOTE_APP_ENV fallback. Worker keepalive/Sentry/telemetry still read workerConfig.appEnv internally, unaffected. Regression tests pass (23/23).