runtimeData carries per-source energy attribution that isn't exposed

[cd34]

runtimeData carries per-source energy attribution that isn't exposed

Stats.totals surfaces the aggregate counters (kwh_sun, kwh_load, kwh_uti_in, ...), but
runtimeData also carries a full source breakdown that the library drops:

kwhSolarLoad  kwhGridLoad  kwhFhpLoad  kwhGenLoad     home supply by source (Wh, today)
soChBat       gridChBat                               battery charge by origin (kWh)
soOutGrid     batOutGrid                              export by origin (kWh)
apowerNumber                                          number of aPower units

Sample from my gateway, mid-morning:

kwhSolarLoad 1003   kwhGridLoad 8855   kwhFhpLoad 5   kwhGenLoad 0
                               sum 9863 Wh   vs   kwh_load 9865 Wh
soChBat 0.005   gridChBat 0.497        soOutGrid 0.02   batOutGrid 0.0

The four load terms reconcile with kwh_load to within 2 Wh.

Why it matters

These answer questions the aggregate counters cannot:

• kwh_uti_in lumps grid→home together with grid→battery. kwhGridLoad separates them, which
  is what you need to know whether a house actually ran on grid power or merely charged from it.
• soChBat/gridChBat give the battery's charge origin, so battery output can be
  attributed back to solar or grid. Without it you have to model the pack and infer.
• soOutGrid/batOutGrid distinguish exporting solar from exporting stored energy.

I built all of this by integrating instantaneous power and modelling the battery as two
origin-tagged pools — and the gateway had been publishing it directly the whole time.

apowerNumber is also handy: mine reports 3, matching the 40.8 kWh nameplate against a
38.4 kWh usable figure I regressed from discharge vs SOC.

Happy to send a PR adding these to Totals (or a separate Attribution dataclass, since they
are a different shape — mixed Wh and kWh units, which is worth normalising). Preference on
naming/shape before I write it?