Encrypted env blob support for varlock run + generated language modules

[theoephraim]

Follow-up to #849, which ships generated env modules for Python/Rust/Go/PHP whose loaders parse the injected __VARLOCK_ENV blob. Today those loaders reject an encrypted blob with a clear error, and varlock run always injects the blob as plaintext — @encryptInjectedEnv only takes effect in the JS auto-load path and build-output integrations.

Goal

Extend the "no plaintext secrets in the process environment" posture (currently JS-only via @disableProcessEnvInjection + @encryptInjectedEnv) to every language with a generated module:

varlock run --inject blob + @encryptInjectedEnv → nothing in the child's environment is plaintext.

This hardens against accidental-exposure classes: APM/error-reporter env snapshots, env dumps in CI logs, grandchild env inheritance, log scrapers. The blob is the worst offender in such dumps — it concentrates every secret in one var whose name matches no redaction heuristic.

Threat-model note (document, don't oversell): the ephemeral key travels in _VARLOCK_ENV_KEY in the same environment (matching the existing JS auto-load design), so this is accident hardening, not a boundary — an attacker with full env read gets ciphertext + key. Out-of-band key delivery (inherited fd/pipe) is a possible later upgrade that doesn't change the blob format; write the loaders so the key source is a seam.

Design

1. varlock run: when settings.encryptInjectedEnv is set and blob injection is on, generate (or reuse) _VARLOCK_ENV_KEY, encrypt the blob via the existing runtime/crypto helpers, inject ciphertext + key. The JS runtime already decrypts (init-server/init-edge), so JS children work with zero changes. With --inject all individual vars remain plaintext — still encrypt the blob (strictly better), but document that the full posture requires --inject blob.

2. Generated loaders — conditional emission. The code generator knows whether the schema sets @encryptInjectedEnv (it has the graph in CodeGenContext), so only emit the decrypt path for schemas that opt in. This preserves the zero-dependency promise for everyone else:

   • Go: stdlib crypto/aes + cipher.NewGCM — no new deps
   • PHP: openssl_decrypt(..., 'aes-256-gcm', ...) — no new deps
   • Rust: add aes-gcm crate to the documented cargo add line
   • Python: guarded cryptography import with a clear "pip install cryptography" error (stdlib has no AES-GCM)

   Format: varlock:v1: + base64(iv[12] ‖ ciphertext ‖ tag[16]), AES-256-GCM, 64-hex-char key from _VARLOCK_ENV_KEY. Make version detection explicit in each loader from day one — a future varlock:v2: fans out across five implementations.

3. Tests: shared cross-language test vectors (fixed key + blob → known plaintext) and an encrypted variant of the smoke-tests/tests/lang-modules.test.ts compile-run suite.

4. Docs: other-languages hub + the four language pages; extend the @disableProcessEnvInjection "no plaintext" story beyond JS; keep the existing clear error as the fallback for stale generated files.

Out of scope

• Out-of-band key delivery (fd/pipe) — later upgrade
• Encrypting individual injected vars