Stepper or Step could be composed of sub-objects reusable by downscaling

[mcgibbon]

Would need to dig a little more and discuss with @frodre and @AnnaKwa if this actually makes any sense, but I thought it at least worth documenting to talk about.

  2. Stepper sub-objects reusable by downscaling (was 2d, reframed)

  Priority: High -- addresses a real cross-cutting concern

  You're right that the Stepper decomposition is already good. The investigation confirmed Stepper is a well-structured composition that delegates to:
  _step_obj (StepABC), _derive_func, _input_process_func, _output_process_func, _parameter_initializer, and forcing_deriver. TrainStepper is a thin
  training-specific wrapper. This is clean.

  The real issue isn't that Stepper is a god-class -- it's that downscaling's DiffusionModel independently reimplements the same core data transformation
  pipeline (normalize -> pack -> model forward -> unpack -> denormalize) that SingleModuleStep already implements. Both use the same Packer and
  StandardNormalizer classes, but compose them independently.

  Components in SingleModuleStep that could directly benefit downscaling if extracted:
  - StaticMasking -- downscaling doesn't use input masking but could (HIGH reuse potential)
  - Derived variables computation -- generic and standalone (HIGH reuse potential)
  - SecondaryDecoder pattern -- diagnostic outputs from primary outputs (MEDIUM)

  Components that are correctly NOT shared due to the time-stepping vs single-step distinction:
  - Multi-step prediction loop (predict_generator)
  - Residual prediction (adding tendency to previous state)
  - Ocean/atmosphere correctors

  Concrete suggestion: The normalize-pack-forward-unpack-denormalize pipeline in SingleModuleStep could be extracted as a reusable ModelPipeline that both
  Stepper and DiffusionModel compose. This wouldn't require DiffusionModel to become a stepper -- it would just share the data transformation plumbing.