refactor: Display-Firmware neutral als P4_Display_Firmware führen

Der Ordner hieß JC_Display_Firmware, bedient seit 1.6.0 aber auch das
Waveshare 7inch DSI LCD (H) am ESP32-P4-Pico. Der Name führte in die Irre.

- JC_Display_Firmware/ -> P4_Display_Firmware/ (samt Sketch, den Arduino
  gleichnamig zum Ordner verlangt)
- Doku/JC-Display_UART-Protokoll.md -> Doku/P4-Display_UART-Protokoll.md,
  Verweise und Titel angepasst
- Verweise in CLAUDE.md, README und Quelltextköpfen nachgezogen

Nur Namen und Pfade, keine Logikänderung. Der Vendor-Ordner
JC_Display_Firmware_7zoll/ behält seinen Namen, ebenso die Bezeichner
JC_PANEL_TYPE/jc_board_bringup im Quelltext.

Enthält außerdem die bereits im Arbeitsverzeichnis liegende, noch nicht
committete Ergänzung des Git-Workflows in CLAUDE.md (PRs über die Gitea-API
statt der hängenden tea-CLI).

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

CLAUDE.md

@@ -11,17 +11,17 @@ für zwei Mikrocontroller, die per UART (230400 8N1, JSON-Zeilen) verbunden sind
   Änderungshistorie: `Changelog.txt` (Root), Version steht in `String version = "…"`.
 
 - **ESP32-P4 – UART-Touch-Display (spiegelt den S3-Zustand).**
-  Ordner: `JC_Display_Firmware/` (Hauptsketch `JC_Display_Firmware.ino`,
+  Ordner: `P4_Display_Firmware/` (Hauptsketch `P4_Display_Firmware.ino`,
   UI in `ui.cpp`/`ui.h`, UART-Protokoll in `protocol_client.*`, LVGL 9.x).
   Hat **kein eigenes WLAN** (der ESP32-C6-Co-Prozessor ist ungenutzt); alle Daten
   kommen über UART vom S3. Eigene Version `DISPLAY_FW_VERSION` +
-  `JC_Display_Firmware/Changelog.txt`.
+  `P4_Display_Firmware/Changelog.txt`.
 
 Wenn ich „S3/Controller/Maschine" sage, ist `Dual_PID_FastHeatUp.ino` gemeint;
-„P4/Display" ist der Ordner `JC_Display_Firmware/`.
+„P4/Display" ist der Ordner `P4_Display_Firmware/`.
 
 **Nicht anfassen:** Der Ordner `Sicherungen/` enthält nur datierte Versions-Backups
-(`.ino`) — niemals dort editieren. Unter `JC_Display_Firmware/JC4880P443C_I_W/` liegen
+(`.ino`) — niemals dort editieren. Unter `P4_Display_Firmware/JC4880P443C_I_W/` liegen
 reine Hersteller-Demos/Beispiele (Board-Support), ebenfalls nicht als Projektcode behandeln.
 
 # Agent Instructions
@@ -33,8 +33,8 @@ reine Hersteller-Demos/Beispiele (Board-Support), ebenfalls nicht als Projektcod
 ## Git-Workflow
 
 - Host: Gitea `git.mueller.black`, Repo `thomas/Dual-PID`, User `thomas`, CLI `tea`.
-- Aenderungen immer ueber Feature-Branch + Merge-Request (`tea pr create`), nie direkt auf `main` committen oder pushen.
-- Pull/Merge-Requests dürfen immer selbstständig gemergt werden (Auto-Merge, kein grünes CI erforderlich, via `tea pr merge` oder Gitea-API); danach den Merge kurz melden.
+- Aenderungen immer ueber Feature-Branch + Merge-Request, nie direkt auf `main` committen oder pushen.
+- PR anlegen **und** mergen bevorzugt über die **Gitea-REST-API** (PowerShell `Invoke-RestMethod` auf `https://git.mueller.black/api/v1/repos/thomas/Dual-PID/pulls[/<nr>/merge]`, Token aus `C:\Users\Thomas\AppData\Local\tea\config.yml`, nur in Variable, nie ausgeben), da die `tea`-CLI gegen `git.mueller.black` oft hängt und nie zurückkehrt. `tea pr create`/`tea pr merge` nur als Ausweichweg. PRs dürfen selbstständig gemergt werden (Auto-Merge, kein grünes CI erforderlich); danach den Merge kurz melden.
 - Kein Force-Push, kein History-Rewrite auf geteilten Branches.
 - Commit-Identitaet bleibt `raw-designs` / `Thomas@raw-designs.de` (globale Git-Config, nicht aendern).
 - Commit-Messages im Conventional-Commits-Format (feat/fix/docs/refactor/...).