docs: rebrand Certifai -> Prüfwerk (user-facing name)

The product is renamed Certifai -> Prüfwerk. This changes only the user-facing
brand text in the documentation (docs/**, VitePress title/name). It does NOT
touch functional identifiers that happen to contain "certifai" (the Docker
network, Keycloak realm/client, Harbor image project, the compliance-* crate
names, or the repo name) — those are infra-coupled and need a separate,
coordinated migration.

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

docs/guide/plc.md

@@ -1,10 +1,10 @@
 # PLC / SPS Projects (CODESYS)
 
-Certifai analyzes industrial control logic (IEC 61131-3) for PLC/SPS targets such
+Prüfwerk analyzes industrial control logic (IEC 61131-3) for PLC/SPS targets such
 as CODESYS projects. A single PLC/SPS target is treated as a **composite device**:
 the control application *and* the device it runs on.
 
-| What you provide | What Certifai does |
+| What you provide | What Prüfwerk does |
 | --- | --- |
 | PLC project (PLCopen XML / ST, or a `.projectarchive`) | **Control-logic SAST** — semantic security rules over ST **and** graphical FBD/LD |
 | A `.projectarchive` | **Control-app SBOM** — the referenced CODESYS libraries + the runtime version, matched against known CVEs |
@@ -28,7 +28,7 @@ Because of this, the device is built along **two independent tracks**, by
 different people, on different timelines, and shipped separately. It also
 inherits the **entire Linux / IT attack surface on top of** the OT / control
 one — which is exactly why a PLC/SPS target is treated as a **composite**:
-Certifai ingests one artifact per layer and scans each with the right pipeline.
+Prüfwerk ingests one artifact per layer and scans each with the right pipeline.
 
 ```mermaid
 flowchart TB
@@ -44,7 +44,7 @@ flowchart TB
     A3 --> DEV(["Running soft-PLC device<br/>SoC + Linux + runtime + control app<br/>Modbus · OPC UA · EtherNet/IP · WebVisu"])
     B3 --> DEV
 
-    subgraph CERT["What Certifai scans — one layer per artifact"]
+    subgraph CERT["What Prüfwerk scans — one layer per artifact"]
         direction LR
         S1["Firmware layer<br/>FirmwareStatic · SBOM · CVE"]
         S2["Control-logic layer<br/>PLC SAST — ST + FBD/LD"]
@@ -70,7 +70,7 @@ flowchart TB
 ::: tip Where Yocto fits
 Yocto is **Track A** — the *build system* for the device platform. It produces
 the Linux image and bakes in the CODESYS runtime, so it is the **firmware
-layer**, entirely separate from the control application. Hand it to Certifai as
+layer**, entirely separate from the control application. Hand it to Prüfwerk as
 its own **firmware image** artifact (scanned by the firmware pipeline, not the
 PLC pipeline). The device OS need not be Yocto — Raspbian/Debian/Buildroot, or
 even an RTOS / bare-metal, are all possible — but Yocto is the common,
@@ -79,7 +79,7 @@ product-grade industrial choice.
 
 ## Two ways to deliver the project
 
-You can either **upload** the project when onboarding, or point Certifai at a
+You can either **upload** the project when onboarding, or point Prüfwerk at a
 **git repository** (recommended — every scan is just a `git pull`, no re-upload).
 
 ### Option A — Upload
@@ -95,7 +95,7 @@ project** artifact and pick its format:
 
 ### Option B — Git repository (recommended)
 
-Attach a **Git repository** artifact to the PLC/SPS target. Certifai clones it and
+Attach a **Git repository** artifact to the PLC/SPS target. Prüfwerk clones it and
 runs the control-logic scan over the exported source in the repo.
 
 ## Best-case git repository layout
@@ -145,7 +145,7 @@ surface real CODESYS advisories as CVE alerts.
 
 ## Dynamic testing — ICS protocol probe
 
-Beyond the static analysis, Certifai can **probe the running device** over
+Beyond the static analysis, Prüfwerk can **probe the running device** over
 industrial protocols. Attach a **Live URL** artifact (the device host / WebVisu
 URL) to the PLC/SPS target and enable the **ICS Probe** scan.