Bump minimum Cantera to `>=3.2` and adopt the modern API ?

Priority: low (tracking issue)

We currently pin cantera >=3.0 in environment.yml and .conda/meta.yaml. Cantera 3.2 deprecates several APIs that RMG still uses. We can't adopt the replacements yet because they break on Cantera 3.1, so for now RMG straddles both versions. Bumping the floor to >=3.2 would let us drop the legacy paths and silence the remaining deprecation warnings without version-gating.

Deprecations that bumping to >=3.2 would let us clean up

1. ct.Arrhenius auxiliary class → ct.ArrheniusRate

class Arrhenius: To be removed after Cantera 3.2. Replace with 'ArrheniusRate'

Used wherever falloff/PLOG rates are assembled:

• rmgpy/kinetics/arrhenius.pyx — Arrhenius.to_cantera_kinetics(arrhenius_class=True) returns ct.Arrhenius(A, b, E). The arrhenius_class flag exists solely to produce this auxiliary object for falloff/PLOG.
• PLOG construction in PDepArrhenius.set_cantera_kinetics builds ct.PlogRate([(P, arr.to_cantera_kinetics(arrhenius_class=True)), ...]).
• rmgpy/kinetics/falloff.pyx — Troe/Lindemann set rate.high_rate / rate.low_rate from ct.Arrhenius objects.

Blocker on 3.1: in Cantera 3.1, PlogRate(...) and LindemannRate.high_rate/low_rate reject ArrheniusRate (TypeError: ... expected cantera.reaction.Arrhenius). In 3.2 they accept ArrheniusRate.

Simplification once on 3.2: drop the arrhenius_class parameter from to_cantera_kinetics() entirely — every caller can use the single ArrheniusRate path, removing the dual-return-type branching.

2. Reactor clone argument

ReactorBase.__init__: After Cantera 3.2, the default value of the 'clone' argument will be 'True' ... Add the 'clone=False' argument to retain the old behavior.

Affects reactor construction in rmgpy/tools/canteramodel.py (IdealGasReactor, IdealGasConstPressureReactor, ReactorSurface).

Blocker on 3.1: the clone= kwarg does not exist in Cantera 3.1 (TypeError: unexpected keyword argument 'clone').

Action once on 3.2: decide explicitly between clone=True (independent copy) and clone=False (shared Solution) and pass it, silencing the warning. RMG sets model.TPX before constructing each reactor and builds a fresh reactor per condition, so either default is functionally correct — but we should make the choice explicit.

Other benefits

• Removes the need to keep testing/maintaining against the 3.0/3.1 behavior of the deprecated APIs.
• Lets us delete the dual-version branching before it accumulates further.

Suggested checklist

• Bump cantera >=3.2 in environment.yml and .conda/meta.yaml (keep them in sync)
• Replace ct.Arrhenius with ct.ArrheniusRate; remove the arrhenius_class flag from Arrhenius.to_cantera_kinetics() and update PLOG/falloff callers
• Add an explicit clone= argument to the reactor constructors in canteramodel.py
• Confirm CI (which now resolves Cantera 3.2) is clean of these deprecation warnings

Other context

Cantera 4 is expected in late summer early fall of 2026, at which point we should probably drop support for 3.1.
We could try this sooner, but it's not urgent.

Start by reviewing the Cantera pins in environment.yml and .conda/meta.yaml, then trace Arrhenius conversion in rmgpy/kinetics/arrhenius.pyx and its PLOG/falloff callers. Check reactor construction in rmgpy/tools/canteramodel.py and run the CI checks that resolve Cantera 3.2. Done means the version pins are synchronized, deprecated API paths and version branching are removed, clone behavior is explicit, and deprecation warnings are gone.