Feat/schema improvements and optimization

[carlosengutierrez]

---

Adds parameter optimization to Neuro-Workflow: a search loop that runs an existing workflow
repeatedly, tunes declared parameters and reports how close each run lands to a declared target.

A workflow is a DAG that runs once; a search is a loop that runs it many times, so the loop sits
outside the graph rather than becoming a node inside it.

What is here

• src/neuroworkflow/optimization/ — the engine: dotted addressing (Node.parameter[.key] to
  tune, Node.output_port[.key] to measure), the spec, a file-based ledger, and optimizer backends
  (random plus Optuna's CMA-ES, TPE, NSGA-II/III). Single-objective backends refuse a
  multi-objective spec rather than inventing weights between objectives.
• NW_Optimization node — declares how to search: algorithm, budget, seed. No ports and no
  process steps, so a workflow containing it executes exactly as it would without it. Its presence
  on the canvas is the signal for the generator to emit an optimization run instead of a single
  execution. Replaces JointOptimizationNode, which was an in-graph grid search.
• Signature-based network reuse — NW_SimConfig rebuilds the SONATA network only when
  something structural changed, so a search does not rebuild it once per trial. Nodes opt in with
  REUSABLE_PATHS; the engine itself stays domain-free.
• Measurements on NW_Analysis — firing_rate_hz and isi_stats per population, so a target
  has something to be compared against.
• Schema — unit and measures on ParameterDefinition; optimization_range accepts a
  per-key dict for dict-valued parameters. Each node instance now carries its own
  NODE_DEFINITION copy, so marking exc optimizable no longer affects inh.

Reporting across objectives in different units

A miss in Hz and a miss in ms cannot be added. Each objective reports its own miss in its own unit,
and the single comparable figure is the worst objective's miss divided by the width of its target
range — printed as furthest from target: probe_isi, 1.4x its target range and stored as
target_ranges_off. Pareto dominance is scale-free and NSGA-II rescales internally, so this
affects reporting and ranking only; what the optimizer is told stays raw and per-objective.

Docs and examples

docs/OPTIMIZATION.md for how the engine works, docs/OPTIMIZATION_GUI_HANDOFF.md for the GUI
half. Five notebooks under notebooks/, two of which show what the code generator should emit.

Not done, and needed before the GUI can use this

optuna and cmaes are not in the nest kernel image. NW_Optimization defaults to cmaes,
so the first optimization generated in the GUI fails on import until one line is added at
Dockerfile.nest:128. Left out of this PR because it forces a rebuild of the nest image; it is
written up as step 1 of the handoff document.

Testing

Single- and multi-objective searches run end to end in Jupyter against real NEST/BMTK, and with toy
nodes for the engine paths. GUI copies under codes/ are synced and byte-identical to src/.