Dynamic defaults for module GUI inputs from tree data

[matt-pharr]

Summary

Module GUI inputs currently support only static default values in gui.json. When a controlling input changes (e.g., switching a machine dropdown from HBT to ITER), other inputs retain their original defaults — the user must manually update every dependent field.

Desired Behavior

Inputs should be able to declare a dynamic default that resolves from the tree, keyed on another input's value. When the controlling input changes, all dependent inputs that the user hasn't manually edited should update to their new defaults.

Proposed Design Direction

• Defaults should come from tree data, not from inline JSON maps in gui.json. Module developers populate a defaults subtree (e.g., tokamaker.defaults.iter, tokamaker.defaults.hbt) in their entry point, and inputs reference it.
• Possible schema: "default_tree_path": "tokamaker.defaults.{machine}.r0" where {machine} is interpolated from the current value of another input.
• This follows the existing options_tree_path and tree_path_input patterns already in the GUI system.
• Need to distinguish between "user edited this value" vs "still at default" so that switching the controlling input only resets un-touched fields.

Existing Patterns to Build On

• visible_if — conditional show/hide based on another input
• options_tree_path — dynamic dropdown options from tree children
• tree_path_input in NamelistEditor — dynamic path resolution from an input value

Motivation

The TokaMaker module needs machine-specific defaults for R0, minor radius, Ip, elongation, triangularity, profile parameters, etc. Without dynamic defaults, switching machines leaves stale values that produce nonsensical equilibria.