Add cybersecurityRequirements[] with allocation, verification, and evidence

[JohnASRG]

Motivation

Issue #45 covers cybersecurity goals, claims, and high-level evidence. That still leaves an ISO/SAE 21434 lifecycle gap: there is no place to record cybersecurity requirements — the layer between a goal and the controls/tests that implement it. Without this, RDX cannot represent allocation to components, verification method, implementation status, or links to test reports — which is exactly what ISO 21434 expects between Clause 9 concept work and Clause 11/12 verification/validation.

Proposed change

Add a new top-level cybersecurityRequirements[] array:

{
  "id": "CSR-001",
  "title": "Authenticate all remote service commands",
  "derivedFromGoalIds": ["CSG-001"],
  "allocatedToComponentIds": ["COMP-TCU"],
  "verificationMethod": "penetration-test" | "code-review" | "fuzzing" | "static-analysis" | "review" | "test" | "analysis",
  "status": "draft" | "approved" | "allocated" | "implemented" | "verified" | "withdrawn",
  "controlImplementationRefs": ["CTRL-001"],
  "evidenceRefs": ["ART-TEST-REPORT-2026-001"],
  "rationale": "...",
  "references": []
}

Add corresponding relationships types: derivesRequirement, allocatedTo, verifies. Update methodology/ISO21434-Mapping.md to show how cybersecurityGoals → cybersecurityRequirements → controls → evidence traces through Clauses 9–12.

References

• AI peer review, section 7 ("ISO 21434 coverage is focused on TARA, but not the full lifecycle")
• Related: #45 (cybersecurityGoals / claims / evidence)

Acceptance criteria

• cybersecurityRequirements[] in JSON Schema + XSD with the fields above
• New relationship types added to the relationships enum
• Example demonstrates a CSG → CSR → control → evidence chain
• methodology/ISO21434-Mapping.md shows the trace
• New requirement IDs added to REQUIREMENTS.md

---

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