bug: stack overflow in earlyResolve() when env flag has circular dependencies

[claude-do]

Description

ConfigItem.earlyResolve() can cause a stack overflow (RangeError: Maximum call stack size exceeded) when the @currentEnv env flag item — or any item resolved early via @import enabled — has circular dependencies.

Root cause

earlyResolve() (packages/varlock/src/env-graph/lib/config-item.ts:272) recursively resolves dependency items without any termination guards:

1. No idempotency check — unlike resolve() (which checks this.isResolved at line 468), earlyResolve() will re-enter items that have already been resolved, causing redundant work on diamond dependencies.
2. No cycle detection — earlyResolve() runs during DataSource.finishInit(), which happens before EnvGraph.finishLoad() where findGraphCycles() is called (line 256). The normal cycle detection safety net does not exist yet at this point in the loading lifecycle.

If a circular dependency exists among items that participate in early resolution, the recursion has no termination condition and the process crashes.

Reproduction

# .env.schema
# @currentEnv=$APP_ENV
# ---
APP_ENV=$OTHER
OTHER=$APP_ENV

Running varlock run (or any command that loads this schema) crashes with RangeError: Maximum call stack size exceeded instead of reporting a schema error.

A self-referencing env flag (APP_ENV=$APP_ENV) also triggers the same crash.

Expected behavior

Circular dependencies in early-resolved items should produce a clear SchemaError / loading error, consistent with how cycles are reported during normal finishLoad() processing via findGraphCycles().

Affected code

• packages/varlock/src/env-graph/lib/config-item.ts — earlyResolve() method (line 272)
• packages/varlock/src/env-graph/lib/data-source.ts — call sites at lines 149, 293, 704

[claude-do]

@mcorrig4 For the upstream submission to dmno-dev/varlock, the recommended workflow is:

1. Open a bug issue on dmno-dev/varlock first — use the same content as this issue. It documents the problem (symptoms, repro steps, root cause) independently from the fix, so anyone who hits the stack overflow can find it even before the PR lands.

2. Then open a PR on dmno-dev/varlock that references the issue — use Fixes #N in the PR body so merging auto-closes the issue. This creates a clean audit trail: issue describes the bug, PR describes the fix, both are cross-linked.

This separation keeps discussions focused — scope/severity/priority on the issue, implementation approach on the PR — and shows the maintainers you've done the analysis before asking them to review code.