Evaluate per-channel square overrides with shared defaults

Summary

As of 2026-04-15, the runtime supports per-channel current_ma in stimulus.channels, but the remaining square/sequence parameters still come from the shared stimulus.square block.

This follow-up is intentionally design-only for now. We are not implementing it immediately.

Goal

Evaluate whether the config should support per-channel square overrides while retaining stimulus.square as shared defaults.

Example target shape:

stimulus:
  channels:
    ch1:
      index: 1
      current_ma: 50
      period_ms: 200
      time_on_ms: 10
    ch2:
      index: 2
      current_ma: 30
      period_ms: 100
      time_on_ms: 5
  square:
    nb_of_seq: 65535
    nb_of_pulses_per_seq: 20
    starting_delay_ms: 0
    delay_between_seq_ms: 3000
    ttl_output: true

Why shared defaults matter

A full migration away from stimulus.square would make configs verbose when channels share the same waveform. Shared defaults with per-channel overrides keeps common cases compact while still supporting asymmetric channels.

Questions to answer

• Which fields should be overrideable per channel: only period_ms and time_on_ms, or the full square/sequence set?
• Should ttl_output be allowed per channel, or remain global?
• How should merge precedence work between stimulus.pulse.*, stimulus.square.*, and per-channel overrides?
• Should preflight/live UI display both effective shared defaults and per-channel resolved values?
• How much test/config churn would this introduce relative to the value it adds?

Expected scope if we choose to do it later

• typed_config.py: channel schema + merge/validation logic
• doric_light_source.py: per-channel hardware settings structure
• hardware_setup.py, stim_controller.py: build resolved per-channel settings
• preflight_ui.py, console_display.py: show resolved per-channel pulse settings
• tests and config overlays

Current decision

Keep current behavior for now. Use this issue to decide whether the design is worth the added complexity before implementation starts.

Start by reading typed_config.py and the current tests and config overlays to trace how stimulus.pulse, stimulus.square, and channel settings are validated and combined. Then inspect doric_light_source.py, hardware_setup.py, stim_controller.py, preflight_ui.py, and console_display.py to map the affected paths. Done means documenting the override scope, precedence, UI impact, and estimated test/config churn, with a recommendation on whether to proceed.