fix(security): deny MCP stdio env vars by runtime family, not exact name (#14641)

The MCP stdio env policy was a flat blocklist of exact variable names, so it
only covered the loader and interpreter variables that had been enumerated when
it was written. Any other variable that a runtime interprets as a code-loading
directive passed validation and was forwarded verbatim into the spawned
server's environment.

The clearest example is the OPENSSL_* family: OPENSSL_CONF points libcrypto at
a config file whose engine/provider sections name a shared object to dlopen, so
an allowlisted package runner whose process links libcrypto would load it. The
same gap covered PYTHONHOME, GIT_SSH_COMMAND, PERL5OPT, JAVA_TOOL_OPTIONS, the
TLS trust-anchor variables, and others.

Replace the exact-name matching with deny-by-default across whole runtime
families (loader, OpenSSL, interpreter option/module paths, package-runner
source overrides, git helper commands, TLS trust anchors, native plugin search
paths), so an unenumerated member of an already-dangerous family is refused
without a code change. SAFE_ENV_VARS carves out the members of those families
that configure behavior rather than load code (PYTHONUNBUFFERED, NODE_ENV, git
commit attribution), and arbitrary vendor-named credentials such as
GITHUB_TOKEN or API_URL keep working, so existing server configs are unaffected.

Add LANGFLOW_MCP_SERVER_ENV_ALLOWLIST for deployments that want the durable
allowlist posture: when set it is authoritative and every name outside it is
rejected; an explicitly empty value rejects all tenant-supplied environment.
Unset preserves current behavior, and production preflight now reports it
alongside the other multi-tenant MCP knobs.

The change is confined to the env-var policy in lfx.base.mcp.security, which is
the single chokepoint the REST validator, the flow-execution sink, and the
pre-spawn check all call.

Fixes LE-2248