Add changeImpactAnalysis[] / delta TARA / R156 software update support

[JohnASRG]

Motivation

UN R156 governs vehicle software update management; R155 expects continuous risk maintenance; the CRA expects ongoing patching obligations. RDX today is essentially a snapshot — there is no first-class way to express "this update changes the risk picture of these components" or to chain delta TARAs across product life. Without this, RDX cannot represent a "living TARA" or feed RXSWIN / software-identification workflows.

Proposed change

Add a top-level changeImpactAnalyses[]:

{
  "id": "CIA-001",
  "changeRef": "SW-UPDATE-2026.4.1",
  "changeKind": "softwareUpdate" | "hardwareRevision" | "configurationChange" | "supplierChange" | "regulatoryChange",
  "affectedComponentIds": ["COMP-TCU"],
  "affectedRiskValueIds": ["RV-001"],
  "affectedControlIds": ["CTRL-001"],
  "rxswinRef": "...",
  "softwareIdentificationRef": "...",
  "impactSummary": "Authentication control changed; retest required",
  "decision": "tara-update-required" | "tara-confirmed-unchanged" | "retest-required" | "accept-residual",
  "approver": "...",
  "decidedAt": "...",
  "rollbackPlanRef": "..."
}

Add relationships types supersedes (RDX-document level) and analyzesChange. Document the recommended "delta TARA" workflow in methodology/: a new RDX document with supersedes: <previous documentId> plus one or more changeImpactAnalyses[].

References

• UN Regulation No. 156 (SUMS)
• AI peer review, "Recommended backlog → changeImpactAnalysis[]" and section 7 ("Change management" missing)
• Related: #47 regulatoryCompliance for R155/R156

Acceptance criteria

• changeImpactAnalyses[] added to JSON Schema + XSD
• Document-level supersedes field added at root
• Example examples/rdx-delta-tara-example.json shows a baseline document and its successor, with one changeImpactAnalysis per affected component
• methodology/ adds a "Continuous risk maintenance & delta TARA" page

---

Surfaced by external AI peer review; see chat transcript for full review text.