Support env interpolation consistently across all config string fields

[christso]

Problem

Environment variable interpolation appears inconsistent across eval YAML fields.

In practice, values like ${VAR} / ${{ VAR }} are resolved in some contexts (for example, certain command/provider fields), but are treated literally in others such as:

• workspace.repos[*].source.path

This blocks portable eval configs that need machine-specific local paths.

Repro

Given an eval file with:

workspace:
  repos:
    - path: ./RepoA
      source:
        type: local
        path: ${{ REPO_A_PATH }}

and environment:

REPO_A_PATH=/abs/path/to/RepoA

running agentv eval ... attempts:

git clone --no-checkout ${{ REPO_A_PATH }} ...

instead of cloning /abs/path/to/RepoA.

Expected behavior

Interpolation should be supported uniformly across all string fields in eval/targets/workspace config (or at least all fields where string values are accepted), not only selected subsets.

At minimum, these should work consistently in all relevant config files:

• ${VAR}
• ${{ VAR }}

Proposal

1. Add a single, centralized interpolation pass for loaded config objects.
2. Apply it recursively to all string-valued fields before validation/execution.
3. Keep behavior backward compatible: strings without interpolation syntax remain unchanged.
4. If a variable is missing, provide a clear error with key and field path.

Why this matters

• Portable eval definitions across dev machines and CI
• No hardcoded absolute paths in committed YAML
• Predictable behavior for users (same syntax everywhere)

Acceptance criteria

1. workspace.repos[*].source.path resolves env variables before clone.
2. Interpolation works in nested objects/arrays of string fields.
3. Both ${VAR} and ${{ VAR }} are supported (or one canonical form is documented + enforced with explicit error for the other).
4. Missing variables produce actionable errors including field path.
5. Existing configs without interpolation continue to work unchanged.

[christso]

Design decision: Missing variable behavior

Acceptance criterion #4 asks for "actionable errors including field path" for missing variables. After discussion, we chose a different approach:

Missing variables resolve to empty string (matching GitHub Actions convention). Field-level validation downstream catches blanks where they're not allowed.

Rationale:

• Some fields legitimately allow empty values — erroring on all missing vars would be too strict
• The interpolation layer doesn't track field paths (it's a generic recursive transformer), so error messages wouldn't include field context
• GitHub Actions uses the same convention, which users already expect from ${{ }} syntax
• Downstream validators already produce clear errors when required fields are empty (e.g., git clone fails with an actionable message if the path is blank)

This satisfies the spirit of the requirement while keeping the interpolation layer simple and composable.