feat(ir): add EnvValue::RuntimeExpression variant to prevent $[] in step env

## Problem

ADO only evaluates $[...] runtime expressions inside job-level ariables: mappings and condition: fields — NOT in step nv: blocks. Putting one in step env passes the literal expression string verbatim.

This has caused bugs at least twice:
- msazuresphere/4x4 build #612528 (synth-PR $[coalesce(...)] in step env)
- PR #1076 Conclusion job ($[dependencies.Agent.result] in step env)

Both were caught by review/tests, but the compiler itself doesn't prevent the mistake.

## Proposal

Add an EnvValue::RuntimeExpression variant (or similar) to the typed IR that:

1. **Accepts** $[...] expressions as a distinct type (not Literal or AdoMacro)
2. **During lowering**, automatically hoists the expression to a job-level ariables: entry with a compiler-generated name
3. **In the step env**, emits a $(generated_name) macro reference pointing to the hoisted variable

This makes it structurally impossible to accidentally put a $[...] expression in step env — the type system forces the correct pattern.

## Additional guard (quick win)

As a complementary measure, add a validation pass (or extend the existing ssert_no_dollar_bracket_in_step_env test helper) that rejects EnvValue::Literal values containing $[ at IR construction time, with an error message pointing to the correct RuntimeExpression variant.

## References

- Existing test guard: \ ests/compiler_tests.rs\ \ssert_no_dollar_bracket_in_step_env()\
- ADO docs on expressions: https://learn.microsoft.com/en-us/azure/devops/pipelines/process/expressions
- Prior fix: \src/compile/filter_ir.rs\ (moved \$[coalesce(...)]\ to Agent job variables hoist)