feat: multicore task architecture

[stritti]

---

Implementierungsstatus

Alle 8 Plan-Tasks umgesetzt, jeweils mit grünem Build (norvi_ae01_r + esp32dev) und passenden Commits:

1. TelemetryQueue — SPSC-Ringpuffer (feste Kapazität) für Publish-Anforderungen; native Tests.
2. SensorSlots — lock-free Temperatur-Slots (Single-Writer SensorTask, Multi-Reader); native Tests.
3. DallasTemperatureNode — loop() in beginMeasurement()/finishMeasurement() gesplittet, liest/schreibt SensorSlots.
4. CoreScheduler + SensorTask — DS18B20 + interne Temperatur auf dediziertem Core-0-Task (Priorität 2, 6 KB Stack); Control-Loop blockiert nicht mehr während der ~750 ms Konvertierung.
5. PublishTask — MQTT-Serialisierung (JSON, HA-Discovery) auf Core 0 (Priorität 1, 4 KB); Loop stellt nur noch Publish-Anfragen in die Queue.
6. DisplayTask (NORVI) — OLED-Rendering (I2C) auf Core 0 (Priorität 1, 3 KB); NorviOledDisplay::loop() in update() (Core 1, Zustandsmaschine) + render() (Core 0, Draw + I2C) gesplittet.
7. Thread-Safety — DegradationManager::reportSensorStatus volatile-Flags (SensorTask → Core 1); SystemMonitor::feedWatchdogFromTask()-Wrapper; nativer Test.
8. Doku-Sync — Architektur-Seiten (EN/DE) an Implementierung angeglichen.

Dokumentierte Abweichungen vom Plan:

• Taster-Abfrage bleibt auf Core 1 (Callbacks mutieren Loop-Singletons — Single-Writer-Regel); ausgelagert ist nur das OLED-Rendering.
• Tests nutzen das projekteigene Test-Framework (kein Unity) — siehe test/native/tests/.
• render() übernimmt zusätzlich drawProgressBar()/display.display()/forceRedraw_-Reset (Plan-Code wäre funktionslos gewesen).
• PublishTask drosselt nur bei aktivem OTA-Update.

Verifikation

• Native Tests: 88 Suites, 187 Assertions, 0 failed (ASAN aktiv).
• Beide Build-Environments: SUCCESS nach Clean-Build, keine neuen Warnings über Baseline.

Manual verification (On-Device-Checkliste)

• Loop-Iteration < 20 ms während Sensor-Reads (Temperatur-Log ansehen bzw. millis()-Delta um context.loop() loggen).
• OLED rendert weiterhin korrekt, Frontpanel-Taster (Navigation, Menü, Long-Press) funktionieren.
• MQTT-Telemetrie-Kadenz unverändert (Discovery nach Reconnect, periodische State-Publishes).
• Keine Watchdog-Resets über 24 h Dauerbetrieb.
• Stack-High-Water-Marks in den Logs prüfen (SensorTask/PublishTask/DisplayTask nach 1 h).

[github-actions]

✅MegaLinter analysis: Success

Descriptor	Linter	Files	Fixed	Errors	Warnings	Elapsed time
✅ ACTION	actionlint	9		0	0	0.4s
✅ BASH	bash-exec	1		0	0	0.22s
✅ BASH	shellcheck	1		0	0	0.28s
✅ BASH	shfmt	1		0	0	0.01s
✅ C	clang-format	1		0	0	0.04s
✅ C	cppcheck	1		0	0	0.02s
✅ C	cpplint	1		0	0	0.37s
✅ CPP	clang-format	80		0	0	0.4s
✅ CPP	cppcheck	80		0	0	8.48s
✅ CPP	cpplint	80		0	0	6.51s
✅ EDITORCONFIG	editorconfig-checker	256		0	0	0.5s
✅ JSON	jsonlint	6		0	0	0.14s
✅ JSON	v8r	6		0	0	3.83s
✅ MARKDOWN	markdownlint	100		0	0	4.06s
✅ YAML	yamllint	25		0	0	0.86s

See detailed reports in MegaLinter artifacts

Your project could benefit from a custom flavor, which would allow you to run only the linters you need, and thus improve runtime performances. (Skip this info by defining FLAVOR_SUGGESTIONS: false)

• Documentation: Custom Flavors
• Command: npx mega-linter-runner@9.6.0 --custom-flavor-setup --custom-flavor-linters ACTION_ACTIONLINT,BASH_EXEC,BASH_SHELLCHECK,BASH_SHFMT,C_CPPCHECK,C_CPPLINT,C_CLANG_FORMAT,CPP_CPPCHECK,CPP_CPPLINT,CPP_CLANG_FORMAT,EDITORCONFIG_EDITORCONFIG_CHECKER,JSON_JSONLINT,JSON_V8R,MARKDOWN_MARKDOWNLINT,YAML_YAMLLINT

Show us your support by starring ⭐ the repository

[github-actions]

Native Test Coverage

Metric	Value
Line Coverage	45.1%
Branch Coverage	60.9%
Lines Hit/Total	237/526
Branches Hit/Total	78/128

Report from native unit tests (ASan + gcov).