Expose runtimeData.mode — it reports when the gateway has overridden the configured schedule

[cd34]

Expose runtimeData.mode — it reports when the gateway has overridden the configured schedule

get_composite_info()["runtimeData"] contains a mode field the library doesn't surface. It
reports what the gateway is actually running, as opposed to what it was configured to run.

It is not a small enum. Running its own schedule it echoes the active tou profile id; it
takes a small code only while something has overridden it.

Evidence

Toggling Storm Hedge in the app, polling every 15s (MDT):

09:53:41   mode 6        stromEn 1     hedge armed  (currendId = 146692)
09:54:14   mode 146692   stromEn 0     disabled -> mode falls back to the profile id
09:57:14   mode 146692   stromEn 1     re-enabled
09:58:18   mode 6        stromEn 1     re-armed

So 6 = Storm Hedge, and an override is mode != currendId. Comparing against workMode
instead is a trap: workMode is 1 while mode is 146692, so that test reports an override
on every normal poll.

Corroborated by behaviour: while mode == 6 the pack sat at 99.8% overnight with the house on
the grid, ignoring the active mode's 40% reserve floor.

Two gotchas for any consumer

• Size. mode holds a six-digit id, so a TINYINT/int8 column silently clamps 146692
  to 127 — a value that looks like data.
• Absence. runtimeData intermittently omits mode entirely: 2 of 14 consecutive polls
  here, no error, every other field present. Treating that as a state change makes an override
  indicator flicker.

Other codes are unknown; I've only observed 6. Would a runtime_mode field on Stats (or a
small overridden helper comparing against currendId) be welcome?