refactor: a solver family's cached data is one object, not eighteen members

[BDonnot]

The bus labelling, Ybus / Sbus, the slack, the pv-pq split and the connectivity
snapshot are one picture of the grid taken at one instant, all of it expressed in
ONE bus labelling. They were eighteen separate LSGrid members, and
pre_process_solver took six of them as parameters while reaching for the other
three itself -- so a caller building into its own vectors got six of its outputs
and the grid got three of them.

That is a real defect in the batch path. A TimeSeries / ContingencyAnalysis prep
wrote its pv-pq split and its slack weights into the grid's cache, next to a Ybus
built for a different labelling, and left that grid still claiming the mixture was
reusable (checked against dev_0.13.2: need_reset_solver() stays false across such
a build). The reuse guard then sized one owner's containers against the other's;
sizes agree far more often than labellings do, so a caller reusing its containers
with a "nothing changed" control would have skipped fillpv_pq and stamped this
grid's split onto its own system -- converged, plausible, wrong. Nothing reaches
it today: the batch works on a private copy and always asks for a full rebuild.
Both of those are accidents, and neither is written down as a requirement.

So rather than adding a check that the nine parts agree, make them one object.

src/core/SolverSideCache.hpp
SolverBusLayout -- labelling, slack, pv-pq split, connectivity snapshot,
allow_reuse, algo_needs_rebuild (types that do not
mention the family's scalar)
SolverSideCache -- the above, plus mat and inj (the two that do)
T = cplx_type -> AC (Ybus / Sbus)
T = real_type -> DC (Bbus / Pbus)

LSGrid holds ac_cache_ / dc_cache_. pre_process_solver / pre_process_dc_solver
take one cache reference. There is no way to hand either half of one.

What this deletes, rather than adds:

• the reuse guard is cache.is_usable(nb_bus), in one place, instead of eight
  comparisons written inline against a mix of two objects' members;
• "is this my cache?" is &c == &ac_cache_, two overloads picked by the family's
  own type, instead of counting nine pointer comparisons and throwing on a
  partial match;
• _mark_cache_valid / prevent_*_cache_reuse / init_bus_status lose their
  if(ac) x_ac_ else x_dc_ bodies;
• BaseBatchSolverSynch's eleven loose members become its own two caches, and the
  read-back of _grid_model.get_ac_pv_solver() -- with the three copies its own
  TODO copies are made here, which is not ideal flagged -- is gone: one call
  fills the whole thing, into vectors the batch owns.

And it is the extension point that was asked for: remote / shared voltage-control
layouts, HVDC droop data, whatever comes next, go in as another field and inherit
the lifetime, invalidation and consistency rules of everything already there.
algo_controler_ (DualAlgoControl) deliberately stays where it is -- it is
threaded through every element container's mutator signature and is already
correctly per family.

Two behaviours change, both in the foreign-build path:

• a build into a caller's cache never reuses (solver_control, the snapshot
  init_bus_status() compares against and the flags it raises all describe THIS
  grid, and say nothing about someone else's cache);
• it retires this grid's cache for that family afterwards. The labelling and the
  split still have to be published, because the NR extensions read them back
  through lsgrid_ptr rather than from what the solver was handed -- including
  bus_pq, which fill_voltage_control_solver_data needs and which the old
  write-through supplied by accident. Publishing the matrix too would mean copying
  it, so what is left is a view for the extensions, not a cache: the snapshot is
  cleared and the control raised, so this grid's next own powerflow rebuilds.
• the grid's own algorithm is no longer reset / reconfigured for a solve it will
  never perform.

ABI: this changes LSGrid's member layout, so a consumer that casts an LSGrid
across a module boundary (gpusim2grid -- see the note that used to sit on
_forced_ref_slack_bus_id) must be rebuilt against these headers. That is already
what docs/solver_plugin.rst requires of plugins ("the same version of
lightsim2grid headers that is installed at runtime ... different BaseAlgo
layout"). Flagged in the changelog.

Cost, callgrind instruction counts (slope between 200 and 1200 powerflows on the
exotic-elements IEEE14 grid, so construction cancels): +200 instr on an AC
powerflow (839 340 -> 839 541, +0.024%) and +214 on a warm-cache DC one
(28 095 -> 28 309, +0.76%, and that is the cheapest powerflow this library can
run). Roughly two thirds of it is not this change: a per-function diff of the
profiles puts +74/pf in compute_results_tsc_rxha_no_amps and +60/pf in an
Eigen::Ref helper, neither of which the diff touches -- inlining decisions that
moved when the translation unit was recompiled. Wall clock shows nothing: the
run-to-run spread on one unchanged binary (2464 -> 2744 ns on the same DC case)
is larger than the gap between the two.

Tests:

• test_cache_reuse.cpp, "the structural half ... unset_changes": the existing
  [unset_changes] sections all reach unset_changes() through
  allow_cache_reuse(false), ie BOTH families off, so the family that runs is
  stopped by is_usable's first line (if(!allow_reuse)) and those sections pass
  with the rest of is_usable deleted. Leaving ONE family automatic is what
  exercises it; verified to SIGSEGV against a build with is_usable gutted to
  return allow_reuse;.
• test_cache_reuse.cpp, "a build into someone else's cache ...": a foreign build
  fills the caller's cache completely, publishes what the extensions read, and
  retires the grid's -- so the grid's own next powerflow is unaffected. The
  need_reset_solver() assertion is the one that separates this from dev_0.13.2.
• test_batch_voltage_control.cpp: the source grid solves identically on both sides
  of a TimeSeries and a ContingencyAnalysis.

Verified: 210 test cases / 5815 assertions pass under Release, under C++14
(LS2G_CXX_STANDARD=14), under ASan+UBSan, and under valgrind (0 errors, no
leaks). The python layer could not be exercised here (no pybind11 / numpy on this
machine); no python-visible API changes.

Signed-off-by: DONNOT Benjamin benjamin.donnot@rte-france.com
Co-Authored-By: Claude Opus 5 noreply@anthropic.com
Claude-Session: https://claude.ai/code/session_01UtvkqXMvgCig75gruZCs7u