resolveFrom honra cualquier SMTP_FROM_* seteado sin validar — Gmail re-estampa el From y el mail sale mal atribuido (ambas vars seteadas en prod)

src/lib/email-aliases.ts:55 resolveFrom(alias): `const v = process.env[envKey]?.trim(); if (v) return v;` — honra cualquier valor seteado, sin validar. Misma clase que el hallazgo SMTP_HOST/PORT/SECURE (f5b4aeb, resolveSmtpConfig) y que PLUTO-676 (OPERATOR_EMAIL). Por que importa aca en particular: el propio header del archivo lo dice — Gmail SMTP RE-ESTAMPA silenciosamente el header From para cualquier direccion que no sea un send-as VERIFICADO en la cuenta. VERIFIED_FROM (soporte-evolutiva-pluto@pensanta.com) es el unico verificado (Elazar confirmo en GWS 2026-06-15). Un SMTP_FROM_* seteado a otra cosa no falla: Gmail lo reescribe al usuario autenticado y el mail vuelve a salir mal atribuido / a spam, que es exactamente el bug que PLUTO-131 arreglo. El fallback si esta bien (cae a VERIFIED_FROM con warn); la rama rota es la que honra el valor. Medido 2026-08-07 (`vercel env ls production`): SMTP_FROM_NOREPLY y SMTP_FROM_NOTIFICACION AMBAS estan seteadas en prod, asi que la rama sin validar es la que corre hoy en cada envio. No es exposicion dormida. Arreglo propuesto: validador en la misma forma que smtp-config.ts / operator-email — parsear la forma `Display Name <addr@dominio>`, exigir que la parte addr sea exactamente el send-as verificado (esto SI es validator-only, a diferencia de OPERATOR_EMAIL: un From no verificado no es una configuracion valida, es el bug), y reportar el rechazo una vez, best-effort, warn/category=email. Reemplazar tambien los dos flags warnedNoreply/warnedNotificacion y el console.warn por el mismo camino de appEvents. Class-A (email-send path): design-ping + diff review de audit. Relacionado: PLUTO-676 (OPERATOR_EMAIL), f5b4aeb (SMTP). Levantado durante PLUTO-676 y filed aparte a proposito, para no ensanchar ese WI en silencio.