Fix: Renovate-CI-Lauf auf stündlich statt wöchentlich erhöht

Beschleunigt Renovates Reaktion auf Dependency-Dashboard-Checkboxen
(die den in renovate.json gesetzten wöchentlichen Update-Schedule
ohnehin umgehen) von bis zu einer Woche auf bis zu einer Stunde.
Tatsächliche neue Update-PRs entstehen weiterhin nur innerhalb des
renovate.json-Schedules (Montag vor 6 Uhr).

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

.gitea/workflows/renovate.yaml

@@ -2,7 +2,7 @@ name: Renovate
 
 on:
   schedule:
-    - cron: "0 4 * * 1"
+    - cron: "0 * * * *"
   workflow_dispatch:
 
 jobs:

AGENTS.md

@@ -131,7 +131,7 @@ Promotion-Flow: `dev` → `testing` → `main`, ausschließlich per Merge (nie d
 - `push` auf `main` (`main.yaml`): Baut Binaries für alle 3 Architekturen, baut `.deb`, `.rpm` und `.pkg.tar.zst`, lädt sie in die Gitea Package Registry hoch, erstellt ein Gitea Release `v<VERSION>` und baut/veröffentlicht das Docker-Container-Image mit den Tags `:latest`, `:<VERSION>`, `:v<VERSION>` und `:<VERSION>.<BUILD_NUMBER>`.
 - `push` auf `testing` (`testing.yaml`): Baut Binaries & Pakete für den `testing`-Kanal, erstellt ein Pre-Release `v<VERSION>-preview` und baut/veröffentlicht das Docker-Container-Image ausschließlich mit eindeutigen Testing-Tags (`:testing`, `:<VERSION>-preview`, `:<VERSION>-testing`, `:<VERSION>-preview.<BUILD_NUMBER>`, `:testing-<BUILD_NUMBER>`). Der Tag `:latest` ist strikt dem `main`-Workflow vorbehalten.
 - `push`/`pull_request`/wöchentlich (`security-scan.yaml`, `trufflehog-scan.yaml`): Trivy (vuln/secret/misconfig) & OSV-Scanner laufen bei Push auf `main`/`testing`/`dev` sowie bei jedem PR; TruffleHog hat **keinen** `branches`-Filter und läuft bei Push auf **jeden** Branch (zusätzlich bei jedem PR). Funde werden per `scripts/report-security-issue.py` als Gitea-Issue gemeldet.
-- wöchentlich, `workflow_dispatch` (`renovate.yaml`): Renovate (containerisiert via `ghcr.io/renovatebot/renovate`) prüft Dependency-Updates, siehe 5.5.
+- stündlich, `workflow_dispatch` (`renovate.yaml`): Renovate (containerisiert via `ghcr.io/renovatebot/renovate`) prüft Dependency-Updates, siehe 5.5. Der stündliche CI-Lauf steuert nur, wie schnell Renovate reagiert (z.B. auf Dependency-Dashboard-Checkboxen); tatsächliche neue Update-PRs entstehen weiterhin nur innerhalb des in `renovate.json` gesetzten `schedule` (Montag vor 6 Uhr).
 
 ### 5.2 Caching (`actions/cache@v6`)
 `main.yaml`/`testing.yaml` cachen mehrere Verzeichnisse, um wiederholte Cross-Compile-Builds zu beschleunigen: