chore(coordinator): 🔧 parent the sub-devices with via_device_id

[rhammen]

🔧 What changed

The four logical sub-devices (heating, domestic water, cooling, ventilation) are now parented to the physical heat pump with via_device_id — the device registry id — instead of the deprecated via_device identifier tuple.

The heat pump is registered explicitly in async_setup_entry via a new LuxtronikCoordinator.async_register_devices(), because via_device_id needs the parent to exist in the registry before the children are built. That also keeps the registry write on an explicit, loop-only path instead of hiding it inside get_device(), which is called from an entity constructor.

❓ Why now

Home Assistant 2026.8 added via_device_id and deprecated via_device; 2026.9 removed via_device from the DeviceInfo TypedDict entirely, which makes the old assignment a basedpyright error as soon as homeassistant-stubs reaches 2026.9. The tuple form is also ambiguous now that device identifiers are only unique per config entry.

Supporting both keys behind a runtime capability check was considered and rejected: tests/requirements-dev.txt pins no Home Assistant version and both CI legs install the current release, so a < 2026.8 branch could never be executed — permanently uncovered code in a repo that enforces 100% coverage.

So hacs.json now declares "homeassistant": "2026.8.0". HACS gates per release, reading the hacs.json of the version being downloaded, so anyone on an older core simply keeps 2026.08.29 and stops being offered updates — nothing breaks for them. That release has been marked as the last one supporting HA ≤ 2026.7, and the README now states the requirement for manual installs, which HACS does not gate.

📦 Also in here

• diagnostics.py: dropped the now-dead "via_device" from TO_REDACT. A registry id is a random hex string; the tuple it replaces embedded the serial number, which is why it was redacted.
• device_infos is built as one map and assigned in a single step — _async_delete_legacy_devices prunes against it, so a half-filled map would read as "these devices are gone".

✅ Verification

Full gate green: 1205 tests pass, coverage stays at 100%, basedpyright 0 errors (the via_device type error is gone), ruff check + format and codespell clean.

Verified on a live install as well — Home Assistant 2026.9.0b4, Container install, with a device registry that already held the four devices created the old way:

name=WP           ident=..._heatpump        via_device_id=None      serial_number=260126_0477
name=Verw         ident=..._heating         via_device_id=1ee1938e  parent=WP
name=Warmwater    ident=..._domestic_water  via_device_id=1ee1938e  parent=WP
name=Koel         ident=..._cooling         via_device_id=1ee1938e  parent=WP

Four devices, not eight, and the user-assigned names survived — name_by_user lives on the device record, so the existing devices were adopted rather than recreated. The deprecation warnings the integration emitted on 2026.9 are gone.

🧪 Tests

TestCoordinatorSubDeviceParenting covers the parenting id, the absence of the deprecated key on all four sub-devices, the heat pump staying unparented while keeping the serial, adoption of an already-registered heat pump without duplication, and the entry-less coordinator the config flow builds.

Resolves #770 (item 1). Item 2 — DeviceEntry.config_entries in _resolve_write_target — is untouched and still works through Home Assistant's compatibility shim, with runway to 2027.8.

🤖 Generated with Claude Code

[github-actions]

Package	Line Rate	Health
custom_components.luxtronik2	100%	✔
Summary	100% (3675 / 3675)	✔