[SPIKE] Evaluate a triliquid mixture through the thermochemical service

[felipebogaertsm]

RocketCEAService is built around a single oxidizer card and a single fuel card, and Propellant.evaluate takes one scalar mixture ratio (machwave/services/cea.py, machwave/models/propellants/categories/base.py). A triliquid feed system can deliver three lines, but the propellant cannot be evaluated at those flows, so the feed system work alone does not make a triliquid runnable.

Scope what blended oxidizer or fuel cards with a weight split would take, what the mixture ratio argument becomes when one side is a blend, and whether the quantized evaluation cache still holds. Independent of the feed system tickets in this milestone; the hybrid case is already covered by #236.

[felipebogaertsm]

Spike findings. Measurements on this machine, rocketcea from the lockfile, N2O/ethanol with water as the third stream.

Blended cards cost nothing at the service layer

generate_card_string already emits a multi-component card with a weight split, and create_cea_service already accepts one through fuel_card_string/oxidizer_card_string. A blend runs end to end today, unchanged:

name Ethanol  C 2 H 6 O 1  wt%=90.0
h,cal=-66200.0  t(k)=298.15  rho,g/cc=0.7890
name Water  H 2 O 1  wt%=10.0
h,cal=-68317.0  t(k)=298.15  rho,g/cc=0.9970

CEA carries the enthalpy of formation and reference temperature per component, so nothing has to be averaged by hand. rocketcea.blends exists but only covers named blends (MON, FLOX, peroxide) plus card utilities; it is not needed here.

The gap is entirely in the propellant model. BiliquidPropellant._validate_components requires exactly two components, and _get_thermochemical_service passes a bare oxidizer name and fuel name with no cards. That is the one place a blend has to be expressed: group the components by role, and emit one card per side with the weight split within that side.

The mixture ratio becomes stream over stream, not species over species

CEA's MR is oxidizer stream mass over fuel stream mass. Fold a diluent into the fuel card and MR means oxidizer / (fuel + diluent), so the same number is a different mixture:

	Tc at Pc = 2 MPa, MR = 4
Pure ethanol	3040.7 K
90/10 ethanol/water	3044.3 K

Stoichiometric N2O/ethanol is O/F ≈ 5.7, so MR = 4 is fuel-rich; diluting the fuel stream moves the actual fuel closer to stoichiometric, and the dilution cooling roughly cancels the shift. The point is not the magnitude — it is that mixture_ratio alone no longer fixes the mixture. The evaluation contract needs the split alongside it, which is what evaluate would grow: evaluate(chamber_pressure, expansion_ratio, mixture_ratio, blend_fractions).

The simulation side already produces both halves. The state totals flow by line role for the mixture ratio, and the per-line flows it already carries are the split.

The cache holds for a fixed split, and needs a second axis for a varying one

Propellant.evaluate quantizes on (chamber_pressure, expansion_ratio, mixture_ratio), and thermochemical_service is a cached_property — one CEA object per propellant.

• Split fixed at design time. Nothing changes. The blend is baked into the card, one CEA object is built once, and the existing key still identifies the evaluation.
• Split varying over the burn. The split is a second state variable, since three lines drain against tank pressures that decay at different rates. Each distinct quantized split needs its own registered card and its own CEA object, so cached_property gives way to a per-split registry, and the key becomes (chamber_pressure, expansion_ratio, mixture_ratio, split).

Cost of that second axis, full property set (flame temperature, chamber, exhaust, specific impulse, condensed fractions):

	per new key
New (Pc, MR) on an existing service	~1.0 ms
New split: register card + build CEA object + evaluate	~1.5 ms

Registration itself is cheap (~0.03 ms); the extra ~0.5 ms is that a fresh CEA object starts with an empty rocketcea memo. The cost risk is not the per-call overhead, it is key count: the cache goes from a plane to a volume, and rocketcea's propellant name registry is global and never evicts, so every distinct split leaks a card for the life of the process.

Suggested split

1. Fixed-split blend. Group components by role with a weight split, emit one card per side, keep the cache as is. Makes a triliquid runnable whenever the diluent is metered at a fixed fraction of its side — the common design case, and it needs no feed-system work at all.
2. Feed-driven split. Add the split as a quantized axis and a per-split service registry, and decide the quantization width against the ~1.5 ms per new split above. Worth doing only once a cycle exists whose diluent line genuinely drifts against its side over the burn.

Item 1 is what unblocks a triliquid end to end. Item 2 is a numerics decision, not a modelling one, and can wait for a real case.