fix(init): 🐛 refuse to set up on a Home Assistant core older than 2026.8

[rhammen]

🔍 What this fixes

#799: a user on Home Assistant core 2026.7.1 updated from 2026.08.29 to 2026.09.14 and almost every heating / DHW / cooling entity went unavailable, with this in the log:

Error adding entity text.luxtronik_..._timer_dhw_schedule_week for domain text with platform luxtronik2
  ...
  device = dr.async_get(self.hass).async_get_or_create(**device_info)
TypeError: DeviceRegistry.async_get_or_create

Since 2026.08.30 (#779) the four sub-devices are parented with via_device_id, a DeviceInfo key the device registry only accepts from core 2026.8. On an older core every entity on a sub-device fails to add with that bare TypeError, while the heat pump device (no via_device_id) sets up fine — a confusing half-broken state that is hard to recognise from the log.

hacs.json already declares "homeassistant": "2026.8.0" and the README already documents the minimum, but a manual install — or HACS letting a release through, which has happened elsewhere — still lands the release on an old core. This PR makes that fail loud instead.

✨ Changes

• const.py — MIN_HA_VERSION: Final[tuple[int, int]] = (2026, 8), the single place the floor lives, with a comment naming the reason (via_device_id).
• __init__.py — _check_ha_version() raises ConfigEntryError (no retry loop; the reason shows on the integration card) when (MAJOR_VERSION, MINOR_VERSION) < MIN_HA_VERSION. The message names the required version, the running version, and 2026.08.29 as the fallback release. Called from both async_migrate_entry and async_setup_entry: guarding migration keeps the entry at a version the fallback release can still load, so a future CONFIG_ENTRY_VERSION bump can't silently break the remedy (a bump is a one-way door — HA refuses to load an entry whose version is newer than the integration's).
• README.md — "HACS will simply not offer you a newer release" softened to "should not", and the note now describes the new error and the two ways out.

Not done on purpose: no dual via_device/via_device_id shim (rejected in #779 — the legacy branch could never be exercised in CI), no guard in the config flow (a brand-new install on an old core still completes the flow and then fails at setup with the same clear message; rare path, not worth the extra code).

🧪 Tests

tests/test_init.py::TestHomeAssistantVersionGuard:

• an old core raises ConfigEntryError from async_setup_entry before connect_and_get_coordinator is called
• an old core raises from async_migrate_entry before the entry is touched (async_update_entry not called)
• the minimum core sets up normally
• hacs.json's homeassistant equals MIN_HA_VERSION, so the two can't drift

Test values derive from the constant, so a future bump is a one-line change. MAJOR_VERSION/MINOR_VERSION are plain ints on release, beta and dev cores (only PATCH_VERSION is a string), so the tuple comparison is safe for 2026.8.0b1 and 2027.1.

Full run: ruff check + format clean, basedpyright 0 errors, codespell clean, 1272 passed, 1 skipped, coverage 100% (unchanged).

🤖 Generated with Claude Code

[github-actions]

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