dev.vars File Fallback

V-3.2.0253 — dev.vars File Fallback: Causa raíz: En el VPS, aun con `nodejs_compat_populate_process_env`, Wrangler 3.114 local no siempre expone las bindings de `.dev.vars` a `process.env` ni a ninguno de los bags de `globalThis` que `getServerEnv` inspecciona. El admin client de Supabase seguía lanzando `legacy Supabase server env error`. Fix mínimo: • `runtime-env.server.ts`: nuevo `readFromDevVarsFile()` que, como último recurso, parsea `.dev.vars` desde `process.cwd()`, `/app/dist/server/.dev.vars` o `/app/.dev.vars`. Resultado cacheado, nunca se loguean valores, `require` lazy para no romper el bundle del cliente. • `detectEnvSource` ahora reporta `dev.vars` como origen válido en el self-check de arranque. • Sólo aplica a código server (helpers, admin clients, RPC, webhooks, cron). NO se tocó ningún `import.meta.env.VITE_*` legítimo del frontend. QA: • `grep -R "legacy Supabase server env error" src` apunta sólo a `client.server.ts` (mensaje legítimo). • `grep -R "process.env para SUPABASE" src` sigue vacío fuera de `runtime-env.server.ts`. • El self-check en el primer init de `getSupabaseAdmin()` ahora muestra `SUPABASE_URL present=true source=dev.vars` cuando Wrangler no populó process.env. No toca: Dockerfile, Wrangler 3.114.14, `--assets ../client`, entrypoint, Traefik, docker-compose ni RLS.