fix: Node-Heap fuer SonarQube-Analyse-Bridge im GitHub-Actions-Runner erhoehen

Nachdem SONAR_TOKEN als GitHub-Secret gesetzt ist (frisches Token vom Besitzer, siehe
CHANGELOG v1.125.2), authentifiziert der Sonar-Schritt jetzt erfolgreich -- scheiterte im
ersten echten Testlauf aber an einem neuen, unabhaengigen Problem: der Standard-Node-Heap
der JS/TS-Analyse-Bridge (~2,2 GB) reicht auf dem GitHub-Hosted-Runner fuer dieses Repo
nicht ("Node.js process running out of memory"). Dieselbe Fehlerklasse wie der
next-build-OOM-Absturz auf dem Produktionscontainer (v1.119.3/v1.119.4).

-Dsonar.javascript.node.maxspace=4096 ergaenzt.

v1.125.3

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

.github/workflows/sonarqube.yml

@@ -36,13 +36,20 @@ jobs:
       - name: Unit tests
         run: npm run test:unit
 
-      # SONAR_TOKEN ist als Repo-Secret nicht gesetzt (Stand 12.09.2026) -- ohne
-      # continue-on-error wuerde dieser Schritt sonst den ganzen Workflow rot faerben,
-      # obwohl Typecheck/Lint/Tests laengst gruen sind. Deckt gleichzeitig den Fall ab,
-      # dass der selbst gehostete SonarQube-Server mal nicht erreichbar ist. Ein "if:" auf
-      # "secrets.SONAR_TOKEN != ''" waere die naheliegende Alternative, macht den Workflow
+      # continue-on-error bleibt auch mit gesetztem SONAR_TOKEN sinnvoll: der selbst
+      # gehostete SonarQube-Server kann mal nicht erreichbar sein, ohne dass das den Rest
+      # des Workflows mitreissen soll. Ein "if:" auf "secrets.SONAR_TOKEN != ''" waere die
+      # naheliegende Alternative fuer den Fall eines fehlenden Secrets, macht den Workflow
       # bei diesem Runner aber ungueltig (0s-Fehlschlag ohne jeden Job-Log) -- deshalb
       # bewusst nur continue-on-error statt eines bedingten Schritts.
+      #
+      # sonar.javascript.node.maxspace=4096: der Standard-Node-Heap der Analyse-Bridge
+      # (rund 2,2 GB) reicht auf dem GitHub-Hosted-Runner fuer dieses Repo nicht --
+      # WeeklyView.tsx allein ist riesig. Ohne das stirbt die Bridge mit "Node.js process
+      # running out of memory", der Scan schlaegt fehl (aufgefangen von continue-on-error,
+      # aber dann laeuft gar keine Analyse). Live beobachtet beim ersten echten Testlauf
+      # mit gueltigem Token am 12.09.2026 -- exakt dieselbe Ursachenklasse wie der
+      # OOM-Absturz von "next build" auf dem Produktionscontainer (siehe CHANGELOG v1.119.4).
       - name: SonarQube scan
         continue-on-error: true
         uses: SonarSource/sonarqube-scan-action@v8.1.0
@@ -54,5 +61,6 @@ jobs:
             -Dsonar.projectKey=mARTin-B78_My-Weekly-ToDo-List_e038f066-0063-4a1e-9c33-03fdd5ab3c3a
             -Dsonar.sources=src,scripts
             -Dsonar.exclusions=**/node_modules/**,**/.next/**,**/*.spec.ts
+            -Dsonar.javascript.node.maxspace=4096
             -Dsonar.qualitygate.wait=true
             -Dsonar.qualitygate.timeout=300

CHANGELOG.md

@@ -2,6 +2,18 @@
 
 All notable changes to this project are documented in this file.
 
+## [1.125.3] - 2026-09-12
+
+### Fixed
+- `SONAR_TOKEN`/`SONAR_HOST_URL` sind jetzt als GitHub-Secret/-Variable gesetzt (frisches
+  Token vom Besitzer erhalten, gleichzeitig `~/.sonar-token` auf dem Spark wiederhergestellt
+  — der nächtliche lokale Scan lief seit mindestens 09.09. fehl). Der Sonar-Schritt im
+  Workflow authentifiziert jetzt erfolgreich, scheiterte im ersten echten Testlauf aber an
+  einem neuen, unabhängigen Problem: der Standard-Node-Heap der JS/TS-Analyse-Bridge
+  (~2,2 GB) reicht auf dem GitHub-Hosted-Runner für dieses Repo nicht — dieselbe
+  Fehlerklasse wie der `next build`-OOM-Absturz von v1.119.3/v1.119.4. Behoben mit
+  `-Dsonar.javascript.node.maxspace=4096`.
+
 ## [1.125.2] - 2026-09-12
 
 ### Fixed

package.json

@@ -1,6 +1,6 @@
 {
   "name": "my-weekly-todo-list",
-  "version": "1.125.2",
+  "version": "1.125.3",
   "description": "A web-based weekly task management application that organizes to-dos and calendar events in a single, intuitive weekly view",
   "main": "index.js",
   "scripts": {