TEL-07: a second MQTT device for inverter B, and A keeps the one it has

MQTT discovery announced ONE device and hung every entity off one unique_id
prefix, so at two inverters B's per-unit telemetry had nowhere to go. It has
somewhere now, and not one entity that already exists moved.

⚠️ THE ASYMMETRY IS DELIBERATE. The first roster entry's per-unit rows are
announced on THE DEVICE IT ALREADY HAS; every later entry gets its own device,
via_device the controller. "One device per inverter" is tidier and is the change
that renames every entity on the live install - and because HA keeps the id it
composed at FIRST discovery, a rename produces a NEW entity beside a DEAD one:
the history stays behind and every dashboard, template and automation naming it
goes on pointing at a sensor that quietly stopped updating, including the three
live watchdog automations. The composed ids come out symmetric anyway
(sensor.goodwe_inverter_a_battery_power / ..._inverter_b_...), so the tidy
design's only real benefit is bought here without its cost.

  * four per-unit rows - setpoint, battery power, SoC, SAFETY-02 sign latch -
    announced only from a roster of two. At N=1 nothing is announced and
    nothing is published: no second device, no renamed entity, no added topic.
  * grid and p1_sample_age_s stay SITE-scoped and are announced ONCE, at every
    roster length 1-6. One P1, one grid connection, and p1_sample_age_s is a
    watchdog input - a second copy is a second answer to "is the meter fresh?".
  * inverter.roster_names() is the one answer to what the units are called,
    read by build_roster() and by the publisher, which must know the roster
    before a Controller exists because announcing happens on the CONNACK.
  * DECISIONS/TEL-07-second-mqtt-device.md records the two designs side by side.

VERIFIED BY DIFFING THE ANNOUNCED PAYLOADS, not by reading the code. The
release/1.0 baseline in test_mqtt.py was generated by running that commit's
module, not transcribed. Roster of one: 9 topics, 0 missing, 0 changed, 0 added.
Roster of two: 0 missing, 0 changed, 8 added.

MEASURED, NOT ASSERTED. Sixteen mutations through tools/mutation_run.sh; twelve
are in the file as a running table, each named with the property it breaks.
Three of those properties exist because the table found their ABSENCE - dropping
the unit from the state topic, moving `grid` into the per-unit set, and
`units=()` in main()'s publisher call were all GREEN on the first run, as was a
roster fallback naming two nameless entries `inverter-a`. Part 9 enumerates what
the file still cannot see, with sizes.

⚠️ INVERTER B DOES NOT PHYSICALLY EXIST (~2026-09-12). Every roster of two here
is SIMULATED, from the datasheet and serial in NOTES.md §1.1b. Nothing about B
has been measured and no entity described here has been seen on a broker.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BwRLw7eKYj2byVdwB6kbjU

goodwe_controller/DOCS.md

@@ -166,6 +166,53 @@ in the log rather than silent, but it is an outage until someone puts the
 single-inverter entity back in that field. **Before downgrading, write down the
 `setpoint_entity` of the unit you want to keep running.**
 
+### What appears in Home Assistant at two inverters
+
+**Nothing you already have changes.** The eight entities this add-on has always
+published — `Setpoint`, `Grid power`, `Battery power`, `Battery SoC`,
+`Circulating power`, `Maintenance phase`, `Controller status`, `P1 sample age` —
+keep their device, their `unique_id`s and therefore their **entity ids and their
+whole recorded history**. At a roster of one, nothing new is announced at all:
+no second device, no renamed entity, not one added topic.
+
+Declare a second inverter and **four rows per unit** appear beside them:
+
+| per-unit row | what it is |
+|---|---|
+| `Setpoint` | this unit's own share of the site target — the number its heartbeat re-emits |
+| `Battery power` | this unit's own reading, `+` = discharging |
+| `Battery SoC` | **this** pack. The site `Battery SoC` row is the *emptiest* pack, which may be the other one |
+| `Sign latch` | this unit's SAFETY-02 latch: `tripped` or `clear` |
+
+⚠️ **The devices are deliberately asymmetric, and it is not an oversight.** The
+first inverter's rows are added to the **existing** *GoodWe* device; every later
+inverter gets its **own** device (*GoodWe Inverter B*), shown in Home Assistant
+as connected via the controller. Home Assistant composes an entity id from the
+**device name plus the entity name**, so giving the first inverter a device of
+its own would rename every entity you already have — and because HA keeps the id
+it composed at first discovery, you would get a new entity beside a dead one:
+the history stays on the old id and every dashboard, template and automation
+naming it silently stops updating. The entity ids come out symmetric anyway —
+`sensor.goodwe_inverter_a_battery_power` beside
+`sensor.goodwe_inverter_b_battery_power`.
+
+**Do not rename the device.** Not in this add-on, and not in Home Assistant's
+device page. It is half of every entity id, including
+`sensor.goodwe_p1_sample_age`, which the ESP32's stale-input watchdog subscribes
+to; a rename disarms that guard by leaving it waiting for a state that never
+arrives, and it fails silently and looks correct.
+
+**`Grid power` and `P1 sample age` stay site-scoped and are announced once.**
+There is one P1 meter and one grid connection; a per-inverter copy would invent
+two of a thing there is one of, and `P1 sample age` is a safety input. Same for
+`Circulating power` (it is a property of the *set* of inverters), the controller
+status, the maintenance phase and the capacity-tariff peak.
+
+⚠️ **Two roster names that differ only in punctuation or case** — `inverter-b`
+and `Inverter B` — are two names to the validator and one id once slugged. The
+add-on gives the second one a `_2` suffix so nothing collides, but the ids you
+get then depend on roster order. Give your inverters plainly different names.
+
 ### P1 meter ingestion
 
 `meter_entity` above expects one signed sensor, which usually means a template