docs: document env var persistence risk in CEL context (#414)

[stack72]

Summary

Closes #414.

Process environment variables exposed via the env namespace in CEL expressions are not filtered or redacted. If a user references env.VAR as a model attribute, the value is written to .swamp/data/ and is visible in swamp data get output — with no warning. This is especially risky for secrets present in the process environment (AWS_SECRET_ACCESS_KEY, GITHUB_TOKEN, database passwords, etc.).

Changes

• design/expressions.md: new ## Environment Variables section placed after ## Sensitive Data. Covers basic usage, a blockquote security warning explaining that env values are unredacted and persisted to disk, and a wrong/right example comparing env.API_KEY (wrong) with vault.get('my-vault', 'API_KEY') (right).

• src/domain/expressions/model_resolver.ts: expanded JSDoc on buildEnvContext() to warn that the full process environment is returned unfiltered and that sensitive vars accessed in CEL will be persisted in model output data. Expanded the ExpressionContext.env field comment with the same guidance and a pointer to vault.get() as the safe alternative.

No runtime behaviour is changed. The vault.get() path already never persists secret values in model output data and is the correct approach for API keys, tokens, and passwords.

Test plan

• deno check — passes (no type changes)
• deno lint — passes (no lint-relevant changes)
• deno fmt — no formatting changes needed
• deno run test — no behaviour changes, all tests should pass

🤖 Generated with Claude Code

[github-actions]

Review: Approved ✅

This is a well-executed documentation PR that addresses issue #414 by warning users about the persistence risk of environment variables in CEL expressions.

What was reviewed:

• Code quality: No runtime changes; JSDoc comments are properly formatted
• CLAUDE.md compliance: ✅ No any types, named exports, proper header
• Domain-driven design: Documentation only, no domain logic concerns
• Test coverage: ✅ No behavior changes, no tests required
• Security: ✅ This PR improves security posture by documenting an existing risk
• Bugs/edge cases: No code changes, no new bugs

Strengths:

1. Clear security warning with blockquote formatting
2. Concrete "wrong vs. right" examples showing env.API_KEY vs vault.get()
3. Lists sensitive env var examples (AWS_SECRET_ACCESS_KEY, GITHUB_TOKEN)
4. Consistent documentation in both design doc and source code JSDoc
5. Links back to the Sensitive Data section for additional context

No blocking issues. LGTM.