feat: Automotive convergence stress test — same capability from many sources (Phase Ω #2)

Not another domain to prove agnosticism (Environmental did that) but a DIFFERENT property: can the
SAME capability be fed by many overlapping Requirement Sources at once without the model becoming
unstable? Realistic setup — a supplier with ISO 9001 + IATF 16949 + TISAX + ASPICE + CSMS + SUMS
developing an ECU for OEM X. Seven sources (CRA, UNECE R155/CSMS, R156/SUMS, IATF, TISAX, ASPICE,
OEM X) with deliberate overlap, run through the SAME engine (0 runtime code, data only).

Three new measurements (user-requested):
  - Capability Convergence: technical_vulnerability_management = 4 sources across 3 source TYPES
    (regulation + certification + contract); secure_signed_update_distribution = 4 sources. The
    overlap is where the economic value lives ("one capability replaces five evidence worlds").
  - Existing-vs-New: 13/27 required caps reuse existing cyber/environmental MCAPs (48%) -> the
    registry is starting to converge; the automotive-specific rest (CSMS/SUMS/ASPICE/functional
    safety) is expectedly new (a maturity hint, not an architecture break).
  - Business Leverage: a convergent capability satisfies N regulations AND unlocks the OEM market —
    more convincing to a GF than "satisfies five laws". (Regulatory Leverage counts regulations;
    Business Leverage counts regulations + markets/customers.)

Ledger gains the automotive row (0/0, 14 new types, data_only); stability stays 7/7 = 100%. The
verdict recommends the user's next step: NOT a new domain but PAUSE and analyse the registry for the
cross-domain high-convergence core MCAPs. Non-runtime -> no deploy. 12 tests pass, check-loc 0.

backend-compliance/reference_scenarios/architecture_stability_kpi.md

@@ -12,11 +12,12 @@ _Der Fokus hat sich verschoben: nicht mehr „kann die Architektur das?", sonder
 | Public Tender (öffentliche Ausschreibung) | cyber | 0 | 0 | 3 | ✅ |
 | OEM Specification (Lastenheft) | cyber | 0 | 0 | 4 | ✅ |
 | ISO 14001 -> Environmental/Material (REACH/RoHS/Batterie/Wasser/Energie/Abfall) | non_cyber | 0 | 0 | 16 | ✅ |
+| Automotive ECU for OEM X (CRA / UNECE R155+R156 / IATF 16949 / TISAX / ASPICE / OEM spec) | cyber | 0 | 0 | 14 | ✅ |
 
-- **Architecture Stability: 6/6 = 100%** der Quellen ohne neue Runtime-Klasse und ohne neue Pipeline.
-- **Knowledge Velocity: 6/6 = 100%** der Quellen **data-only** integriert (kein Entwickler nötig).
-- **Generalität über Cyber hinaus: 1/6 Quellen NICHT-Cyber** (Umwelt) — trugen die Pipeline ebenfalls 0/0. Das ist der eigentliche Test (ein anderes Denkmodell, nicht noch ein Cyber-Regelwerk).
-- **Capability-Modell-Frühindikator: 45 neue Typen gesamt, Maximum 16** (Umwelt, erste Nicht-Cyber-Domäne) — in Range, KEIN Granularitätsalarm (Alarm ≈ eine Domäne braucht plötzlich ~80 neue Typen bei 0 Runtime-Change → Modell zu grob/fein).
+- **Architecture Stability: 7/7 = 100%** der Quellen ohne neue Runtime-Klasse und ohne neue Pipeline.
+- **Knowledge Velocity: 7/7 = 100%** der Quellen **data-only** integriert (kein Entwickler nötig).
+- **Generalität über Cyber hinaus: 1/7 Quellen NICHT-Cyber** (Umwelt) — trugen die Pipeline ebenfalls 0/0. Das ist der eigentliche Test (ein anderes Denkmodell, nicht noch ein Cyber-Regelwerk).
+- **Capability-Modell-Frühindikator: 59 neue Typen gesamt, Maximum 16** (Umwelt, erste Nicht-Cyber-Domäne) — in Range, KEIN Granularitätsalarm (Alarm ≈ eine Domäne braucht plötzlich ~80 neue Typen bei 0 Runtime-Change → Modell zu grob/fein).
 
 ## Ehrlichkeit: die Pipeline-Funktionen sind EINMALIG (jetzt eingefroren)
 - 6 domänen-AGNOSTISCHE Funktionen, einmal gebaut, nicht je Domäne: `transition_reasoning (RS-005)`, `optimization`, `journey_matcher (ADR-011)`, `playbook`, `completeness`, `company (2A)`.
@@ -30,8 +31,8 @@ _Der Fokus hat sich verschoben: nicht mehr „kann die Architektur das?", sonder
 | **Produktion** (wie TUN/BEWEISEN) | Playbooks, Verification, Reference Scenarios |
 
 ## Die drei Erfolgsfragen ab jetzt (statt Coverage)
-1. **Musste für eine neue Domäne Runtime-Code geändert werden?** → bisher: **nein** (6/6).
-2. **Knowledge Velocity** — neues Wissen ohne Entwickler aufnehmbar? → bisher: **ja** (6/6 data-only).
+1. **Musste für eine neue Domäne Runtime-Code geändert werden?** → bisher: **nein** (7/7).
+2. **Knowledge Velocity** — neues Wissen ohne Entwickler aufnehmbar? → bisher: **ja** (7/7 data-only).
 3. **Architecture Stability** — bestehende Capability/Journey strukturell ändern oder nur Daten ergänzen? → bisher: **nur Daten**.
 
 > **Befund:** Über fünf Zielarten und sechs Quellen blieb `Reality → Evidence → Capability → Required → Delta → Journey → Roadmap → Playbooks → Verification` unverändert. Das ist der eigentliche Nachweis: keine Compliance-Architektur, sondern eine allgemeine Requirements-Verifikationsarchitektur, die ihre Generalität UNTER realer fachlicher Belastung behält. Der nächste Test ist nicht ein Feature, sondern die nächste echte Domäne (Umwelt-Cluster · Automotive · Medizintechnik · Payment) — jede als neue Ledger-Zeile, bei stabilem KPI.