materialize_clock! in the constructor doesn't prevent MLIR-level aliasing
that occurs at runtime inside tick! when both last_Δt and last_stage_Δt
are assigned the same Δt value. The optimization_barrier is still needed
until Reactant provides a proper buffer copy op.

See #5389 (comment)

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>

* Fix XLA buffer donation error from aliased clock fields in tick!

In tick!, both clock.last_Δt and clock.last_stage_Δt were set to the
same Δt.mlir_data, causing them to alias. Inside @trace for loops,
this triggers "Attempt to donate a buffer which is also used by the
same call to Execute()" because XLA tries to donate one while reading
the other in the while loop carry. Break the alias by creating a copy
via Δt + zero(Δt) for last_stage_Δt.

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>

* Remove initialization_update_state! and clean up initialization

Replace the confusing `initialization_update_state!` with a clear separation
of concerns between `reconcile_state!`, `initialize!`, and `update_state!`:

- `reconcile_state!`: ensures auxiliary state (barotropic velocities, vertical
  coordinate scaling) is consistent with prognostic fields. Called in `set!`
  and `initialize!`. Idempotent.

- `initialize!`: one-time setup before first time step. Calls `reconcile_state!`,
  synchronous halo fills, and `initialize_closure_fields!`. Allowed to be
  non-idempotent.

- `update_state!`: idempotent recomputation of diagnostics/derived quantities.
  Called every time step and after `set!`.

Renames:
- `initialize_free_surface!` → `reconcile_free_surface!`
- `initialize_vertical_coordinate!` → `reconcile_vertical_coordinate!`
- `maybe_initialize_state!` → `maybe_initialize!` (now also calls `initialize!`)

The `set!` function gains a `reconcile_state` kwarg (default `true`) for
advanced users who set barotropic velocities independently.

Bump version to 0.106.1.

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>

* Remove initialize! call from maybe_initialize!

maybe_initialize! should only call update_state!, not initialize!.
Calling initialize! inside time_step! would cause double-initialization
when used with Simulation (which already calls initialize! in
Simulation.initialize!).

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>

* Rename maybe_initialize! to maybe_prepare_first_time_step!

Also move reconcile_state! definition to TimeSteppers (where update_state!
lives) and call it from maybe_prepare_first_time_step! so that bare
time_step!(model, Δt) reconciles state on the first step.

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>

* Use optimization_barrier instead of +zero to break clock field alias

XLA folds Δt + zero(Δt) → Δt, so the aliasing between last_Δt and
last_stage_Δt persists. Use Reactant.Ops.optimization_barrier which
XLA cannot fold, ensuring distinct buffers for the while loop carry.

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>

* Add materialize_clock! and remove optimization_barrier from tick!

Add `materialize_clock!(clock, timestepper)` called in HFSM and NH model
constructors. For QuasiAdamsBashforth2TimeStepper, this sets
`clock.last_Δt = clock.last_stage_Δt` to ensure they are distinct objects.
This is needed for Reactant, where aliased ConcreteRNumber fields cause
XLA buffer donation errors in compiled loops.

With materialize_clock! breaking the alias at construction time, the
optimization_barrier workaround in the Reactant tick! override is no
longer needed and is removed.

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>

* Restore optimization_barrier in Reactant tick!

materialize_clock! in the constructor doesn't prevent MLIR-level aliasing
that occurs at runtime inside tick! when both last_Δt and last_stage_Δt
are assigned the same Δt value. The optimization_barrier is still needed
until Reactant provides a proper buffer copy op.

See #5389 (comment)

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>

* Remove optimization_barrier from Reactant tick!

materialize_clock! in the model constructor ensures last_Δt and
last_stage_Δt are distinct ConcreteRNumber objects. Assigning the same
value to both in tick! via .mlir_data does not re-alias the objects.

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>

* Move materialize_clock! QAB2 method to Reactant extension

For QAB2, last_Δt and last_stage_Δt always hold the same value after
tick!. In the Reactant extension, materialize_clock! aliases them via
setfield! (bypassing the ReactantClock setproperty! override) so that
Reactant's tracer sees one buffer, avoiding XLA buffer donation errors.

The src/ QAB2 method is removed since aliasing is only needed for
Reactant's ConcreteRNumber fields (normal Float64 fields are immutable
values with no aliasing concern).

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>

* rm stale import

* fill free surface halos before timestepping

* remove stale imports

* add fill halos in reconcile_state!

* now just need to fix multi-region

* cubed sphere implementation

* fix the dispatch

---------

Co-authored-by: Claude Opus 4.6 (1M context) <[email protected]>
Co-authored-by: Simone Silvestri <[email protected]>