feat(onboarding): surface curated expert text + human capability labels (advisor was showing snake_case)

The advisor was structurally correct but unusable: every question showed a snake_case capability id plus a
single generic fallback reason ("Keine Anhaltspunkte im Unternehmensprofil — klären"). The expert text
already EXISTED in the transition patterns (why_asked / reviewable_claim) — the pipeline just dropped it.

  - transition_reasoning: TargetRequirement gains `rationale`; assess_transition uses it as the request
    reason when present, else the generic fallback (additive, backward-compatible for all consumers).
  - onboarding_service._target carries the pattern's why_asked (delta) and reviewable_claim (likely_covered)
    into the requirement rationale -> the question's `why`.
  - knowledge/onboarding/capability_labels.yaml: curated DE labels (id -> human), reusable across targets;
    labels_for() + response.capability_labels expose them; the frontend renders label || prettified id.

Now ISO27001->TISAX reads "Auftragsverarbeitung (Art. 28 DSGVO) — If a TISAX data label is in scope, you
must show Art. 28 GDPR processing-on-behalf controls; ISO 27001 does not establish these." instead of
"data_protection_processing_on_behalf — klären". why_asked text is still EN (existing knowledge; translation
is curation). 34 onboarding+transition tests pass, mypy --strict clean (13 modules), check-loc 0.

backend-compliance/compliance/transition_reasoning/schemas.py

@@ -70,6 +70,7 @@ class TargetRequirement(BaseModel):
 
     capability_id: str  # MCAP-...
     question_intent: str = "verify_existence"  # passed through to the request, not rendered
+    rationale: str = ""  # curated human text (e.g. why_asked / reviewable_claim) — surfaced as the request reason
     expected_evidence: List[str] = Field(default_factory=list)
     source_control_id: Optional[str] = None
     supports_obligations: List[str] = Field(default_factory=list)