Fix Mixed Thermo Type Handling

[kavanase]

Fixes #1104

Summary

emmet's thermo builder runs with use_max_chemsys=True, so a material's ThermoDoc is only emitted by the build for its own chemical system; e.g. elemental Cs from a Cs build, CsI from Cs-I, Cs₂TiI₆ from Cs-I-Ti etc. For GGA_GGA+U_R2SCAN the stored ConstantEnergyAdjustment is hull-referenced to that (chemical sub-system) build, and MaterialsProjectDFTMixingScheme picks its reference functional per chemical system.

get_entries_in_chemsys pools the docs of every subsystem, so it mixes two absolute energy scales; GGA(+U) and r2SCAN. For the Cs-Ti-I example, that is r2SCAN for Cs and Ti chemsyses, and GGA(+U) for I, Cs-I, I-Ti, Cs-I-Ti; resulting in the spurious +4.57 eV/atom formation energy. #1087 flipping the default to the mixed hull is what exposed this issue.

Essentially, the DFT-mixing hull-referenced corrections are only meaningful relative to the hulls they were computed on.

The proposed fix here is to take the mixed entries from the phase diagram MP builds for the whole system, where the mixing was applied across every subsystem at once. I also tested the workaround noted in #1104 (re-apply the mixing scheme after mprester pull); it fixes Cs-Ti-I but isn't general, because the mixing scheme is still chemsys-scoped. With this fix, re-mixing remains a fallback where MP has no pre-built diagram (e.g. Ba-Cs-I-Ti) or the entries need reshaping first, with a warning that the result may differ from materialsproject.org. Queries that can't be served on one scale at all (narrowed additional_criteria, compatible_only=False) now also warn.

Additional minor fixes:

• get_entries discarded entry.data when property_data was passed, losing oxidation_states. MaterialsProject2020Compatibility uses oxidation_states (re-guessing if not present) so keeping them is important for consistency. e.g.; it re-guesses mp-761189 wrong and gives a 0.182 eV/atom difference in energy relative to MP (superoxide vs peroxide).
• additional_criteria replaced the default thermo type rather than narrowing it, so {"is_stable": True} ran unfiltered and pooled all three thermo types.
• get_stability re-mixed already-mixed entries. For Cs-Ti-I it fed 48 entries in and got 19 out, with all 29 r2SCAN entries and every ternary discarded causing No valid decomposition found ValueErrors. Fixed; now returns 0.0 for Cs₂TiI₆ as expected.

Verification:
Hull distances match MP's energy_above_hull to 0.0 eV/atom with no material missing across Cs-Ti-I, H-O, Na-Cl, Ba-Ti-O, Sr-Ti-O, Zn-O, Li-Mn-O, Cs-Pb-I, Ag-Bi-I, Y-Ba-Cu-O, Fe test systems, plus the no-diagram fallback on Ba-Cs-I-Ti. New test test_get_entries_in_chemsys_mixed_hull checks Cs₂TiI₆ is correctly placed on the hull and H-O matching MP values with nothing missing.

Behavioural changes to flag:

• This approach is unfortunately ~6 s slower for small systems (Cs-Ti-I 0.7 s → 6.4 s; due to the phase diagram download), but does not scale much with system size.
• get_stability still reconstructs mixing corrections locally, so it can disagree with get_entries_in_chemsys on edge cases like Na-Cl-like systems. Placing a user entry on MP's hull needs both functionals side by side, which the pre-built diagram doesn't carry.
• test_get_stability[GGA_GGA+U_R2SCAN] still can't be un-skipped: its own reference re-mixes already-mixed entries, and its bare ComputedEntry inputs have no structures for the scheme to match on.

Checklist

• Google format doc strings added. Check with ruff.
• Type annotations included. Check with mypy.
• Tests added for new features/fixes.
  - [ ] If applicable, new classes/functions/modules have duecredit @due.dcite decorators to reference relevant papers by DOI (example)