feat: update-Entitaet fuer die Firmware und das Testgeruest

Aufgebaut wie ha-ninlight: die Abbilder liegen unter ninstrip_firmware im
Konfigurationsverzeichnis, Home Assistant liefert sie selbst unter einer
einmaligen Adresse aus, und zwar genau die Bytes, die vorher geprueft
wurden. Dazu firmware.py (Anhaenger, Versionsreihenfolge, WLAN-Pruefung,
Katalog), http.py, urls.py und shared.py.

Drei Unterschiede zu ninlight, alle aus der Firmware heraus:

* Verglichen wird device_type - die Platine -, nicht product. Letzteres ist
  bei allen Platinen 'ninstrip'; die Abbilder unterscheiden sich aber hart,
  die K1Y invertiert das Datensignal und die KL-RGBC3 nicht. Firmware ohne
  dieses Feld bekommt gar kein Angebot.
* Die WLAN-Pruefung sucht die SSID unverpackt: ein ESP32-Abbild ist nicht
  gzip-verpackt wie das des W600. An einem mit sdkconfig.local gebauten
  Abbild gegengeprueft - die SSID steht genau einmal NUL-gerahmt drin.
* Der Fehlerschluessel heisst device_url_too_long statt lamp_url_too_long.

Dazu das Testgeruest, das es hier bisher gar nicht gab: 204 Tests in
tests_unit/ (ohne HA-Instanz) und tests/ (mit), Abdeckung 97 %, dazu
scripts/check.sh als Ersatz fuer die fehlende CI. Die Nutzdaten in
tests_unit/samples.py sind an der Stehlampe abgefragt.

Beim Gegenpruefen per Mutation fiel auf, dass die Platinenpruefung
unmittelbar vor dem Senden ungeprueft war - der Test dazu ist jetzt da und
faellt, wenn man die Pruefung entfernt.

README.md

@@ -54,6 +54,7 @@ Ohne mDNS geht es auch von Hand über Adresse und Token.
 | `number` | sACN-Universe und -Startslot |
 | `select` | Verhalten nach Stromende (`release` / `hold`) |
 | `binary_sensor` | sACN aktiv, Multicast beigetreten (letzterer standardmäßig aus) |
+| `update` | Firmware-Aktualisierung aus dem Abbild-Ordner |
 
 Die Diagnose-Sensoren sind standardmäßig abgeschaltet; die
 Leistungsbegrenzung ist an, weil sie verrät, ob die Strombegrenzung gerade
@@ -66,8 +67,43 @@ eine Farbe, die stimmen würde. Die Segmente stellt man über Szenen.
 ## Noch nicht drin
 
 - Einzelne Segmente als eigene Entitäten
-- Firmware-Aktualisierung über eine `update`-Entität (die Firmware kann OTA
-  mit Rückfallebene, die Integration nutzt es noch nicht)
+
+## Firmware-Aktualisierung
+
+Aufbau wie ha-ninlight. Die Abbilder liegen im Ordner **`ninstrip_firmware`**
+unterhalb des Konfigurationsverzeichnisses; `tools/release_images.sh` der
+Firmware baut sie. Alle fünf Minuten wird der Ordner durchgesehen.
+
+Home Assistant liefert das Abbild selbst aus, unter einer **einmaligen
+Adresse**, die nur gilt, solange die Aktualisierung läuft. Das Gerät kann sich
+bei Home Assistant nicht anmelden — der unratbare Schlüssel ist der Schutz.
+Ausgeliefert werden genau die Bytes, die vorher geprüft wurden; wird die Datei
+mittendrin überschrieben, ändert das nichts mehr an dem, was ankommt.
+
+Drei Dinge entscheiden, ob ein Abbild angeboten wird:
+
+- **Die Platine muss passen.** Verglichen wird `device_type` aus
+  `system/info` mit dem Typ im NINL-Anhänger des Abbildes
+  (`ninstrip-rgbc3`, `ninstrip-k1y`). `product` ist bei allen Platinen
+  `ninstrip` und taugt dafür nicht: ein K1Y-Abbild invertiert das
+  Datensignal, ein KL-RGBC3-Abbild nicht — die falsche Wahl lässt den Strip
+  dunkel. Firmware vor `v0.1.0` meldet kein `device_type` und bekommt
+  deshalb gar kein Angebot.
+- **Die Version muss vergleichbar und neuer sein.** Gerechnet wird nach
+  `git describe`, nicht mit der Versionslogik von Home Assistant: die hält
+  `0.1.0-12-g71a57` und `0.1.0-47-g71a57` für denselben Versionskern.
+  Firmware vor dem Tag `v0.1.0` meldete nur einen Hash — daran lässt sich
+  keine Reihenfolge ablesen, also gibt es auch kein Angebot.
+- **Die WLAN-Zugangsdaten müssen drin sein**, solange das Gerät sein WLAN
+  nur aus der Firmware kennt (`wifi.source` = `compiled`). Sonst verlöre es
+  nach dem Update seine Netzverbindung. Fehlen sie, erscheint ein Hinweis in
+  den Reparaturen statt eines Angebots. Wer das Gerät über das Onboarding ins
+  WLAN gebracht hat (`stored`), bekommt das Update ohne diesen Vorbehalt.
+
+Die Geräte laden nur über **schlichtes http**. Erreichen sie die interne
+Adresse von Home Assistant nicht so, trägt man in den Einstellungen der
+Integration eine eigene ein (`http://…`, höchstens so lang, dass die ganze
+Firmware-Adresse unter 255 Zeichen bleibt — mehr nimmt das Gerät nicht an).
 
 ## sACN / E1.31
 
@@ -97,3 +133,24 @@ geht dann trotzdem.
 
 Die Integration wird in der gemeinsamen Dev-Instanz `ha-dev` per Mount
 eingebunden, der Quellcode bleibt in diesem Repo.
+
+### Tests
+
+```
+uv venv -p /opt/homebrew/opt/python@3.14/bin/python3.14 .venv
+uv pip install --python .venv/bin/python -r requirements_dev.txt
+./scripts/check.sh
+```
+
+`scripts/check.sh` ersetzt die CI — das Repo liegt in einem privaten Gitea
+ohne Actions — und läuft über ruff, die Tests samt Abdeckung (mindestens 95 %)
+und die Übersetzungen.
+
+Die Tests liegen in zwei Ordnern: **`tests_unit/`** kommt ohne
+Home-Assistant-Instanz aus (API-Client gegen einen echten lokalen Server,
+Anhänger, Versionsreihenfolge, Adressen), **`tests/`** fährt eine
+Home-Assistant-Instanz hoch. Die Nutzdaten in `tests_unit/samples.py` sind an
+echten Geräten abgefragt, keine erfundenen.
+
+Die Python-Version ist nicht beliebig: Home Assistant 2026.9 verlangt
+mindestens 3.14.2, und auf PyPI liegt diese HA-Version nur für uv bereit.