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/knowledge/architecture_stability/integration_ledger.yaml

@@ -76,6 +76,16 @@ sources:
     integration_kind: data_only
     family: non_cyber          # FIRST non-cyber domain — the real generality test
     exercised_by: "customer_mission_5, environmental_stress_test"
+  - source: "Automotive ECU for OEM X (CRA / UNECE R155+R156 / IATF 16949 / TISAX / ASPICE / OEM spec)"
+    domain: automotive
+    target_type: multi_source   # 7 OVERLAPPING sources spanning regulation + certification + process + contract
+    integrated_as: multi_source_required_set
+    new_runtime_classes: 0
+    new_pipeline: false
+    new_capability_types: 14    # of 27 required caps, 13 reuse existing MCAPs (48% -> registry converging)
+    integration_kind: data_only
+    family: cyber               # convergence test: same capability fed by many sources, model stayed stable
+    exercised_by: "automotive_convergence_stress_test"
 
 # --- One-time, domain-AGNOSTIC pipeline functions (built once, now FROZEN per Phase Ω). ---
 # Listed for honesty so the stability KPI cannot be gamed: these are NOT per-domain costs. The last

backend-compliance/knowledge/domains/automotive/source_capabilities.yaml

@@ -0,0 +1,58 @@
+# Automotive multi-source capability data — the CONVERGENCE stress test (Phase Ω, test #2).
+#
+# Not another domain to validate domain-agnosticism (Environmental already proved that). This tests a
+# DIFFERENT property: can the SAME capability be fed by MANY different Requirement Sources at once
+# without the model becoming unstable? Realistic setup: a supplier developing an ECU for OEM X, who
+# already holds ISO 9001 + IATF 16949 + TISAX + ASPICE (L2/3) + CSMS + SUMS.
+#
+# Each source lists the capabilities it REQUIRES. Overlap is deliberate and realistic — that overlap is
+# exactly where the economic value lives ("one capability replaces five evidence worlds"). Capabilities
+# are VERBS / stable ids reused from the cyber + environmental patterns where they recur, so the
+# existing-vs-new (registry convergence) measurement is honest. Data only — no runtime code.
+
+goal: "Develop a new ECU (Steuergerät) and supply OEM X."
+
+sources:
+  - id: CRA
+    type: regulation
+    requires: [secure_signed_update_distribution, technical_vulnerability_management,
+               coordinated_vulnerability_disclosure, sbom_creation, access_control_and_authentication,
+               incident_management, secure_development_lifecycle, product_cyber_risk_assessment]
+  - id: UNECE_R155_CSMS
+    type: regulation
+    requires: [secure_signed_update_distribution, technical_vulnerability_management,
+               product_cyber_risk_assessment, incident_management, access_control_and_authentication,
+               cybersecurity_management_system, threat_analysis_and_risk_assessment]
+  - id: UNECE_R156_SUMS
+    type: regulation
+    requires: [secure_signed_update_distribution, software_update_management_system,
+               identify_software_versions_rxswin, document_update_campaigns]
+  - id: IATF_16949
+    type: certification
+    requires: [document_and_change_control, supplier_evaluation, release_and_approval_process,
+               approve_production_parts_ppap, plan_product_quality_apqp]
+  - id: TISAX
+    type: certification
+    requires: [information_security_management, access_control_and_authentication, incident_management,
+               technical_vulnerability_management, supplier_security, protect_prototypes]
+  - id: ASPICE
+    type: process
+    requires: [assess_software_process_capability, engineer_requirements_process,
+               verify_software_process, manage_configuration_process]
+  - id: OEM_X_Spec
+    type: contract
+    requires: [secure_signed_update_distribution, technical_vulnerability_management,
+               provide_functional_safety_evidence, protect_prototypes, supplier_security,
+               identify_software_versions_rxswin, provide_dedicated_security_contact]
+
+# The company's certificates/processes -> the capabilities they make probably-present (Welt-1).
+# (Management/process discipline + the security baseline an automotive supplier with these certs has.)
+company_profile_capabilities:
+  ISO9001:    [document_and_change_control, supplier_evaluation, release_and_approval_process]
+  IATF16949:  [approve_production_parts_ppap, plan_product_quality_apqp]
+  TISAX:      [information_security_management, access_control_and_authentication, incident_management,
+               technical_vulnerability_management, supplier_security, protect_prototypes]
+  ASPICE:     [assess_software_process_capability, engineer_requirements_process,
+               verify_software_process, manage_configuration_process]
+  CSMS:       [cybersecurity_management_system, threat_analysis_and_risk_assessment, product_cyber_risk_assessment]
+  SUMS:       [software_update_management_system, document_update_campaigns]