Studio · task 0.3 — dependency-graph engine and override semantics

[aliakherati]

Phase 0, task 0.3 — see docs/studio/plan/PHASE_0.md. Taken after 0.5, so the engine resolves real derivations rather than fixtures.

The mechanism that makes "go back and edit stage 1 without losing your stage 6 choices" correct by construction. It is a data-model problem, not a UI problem.

Scope

• Build an explicit DAG from derived_from metadata.
• On a change to field X, compute the downstream closure. For each downstream field: auto → recompute silently; user_override → do not overwrite, mark stale, and present the old value, the newly-derived value, and a choice.
• Never persist an internally inconsistent config without an explicit stale_fields list attached.
• Tests assert that changing an upstream field recomputes exactly the expected downstream set and preserves overrides.

Acceptance

• The registry of derivations is complete with respect to the schema: every DERIVED field has one, and its declared inputs match the field's derived_from exactly. A mismatch is a test failure, not a silent no-op.
• Chained derivations resolve in dependency order (so2_initial_pptv depends on plume_volume_cm3, which is itself derived).
• Cycles raise rather than hang.
• Resolution stays cheap enough to run on every keystroke: no coupled import, no JAX.

Base branch: studio/dev.