Preserve assumed-system requirement traceability without rendering inherited requirements as standalone ASR pages

### Feature Request / Modification Description

Assumed System Requirements (ASRs) referenced by Feature Requirements through derived_from must be available to component traceability processing. Currently, this propagation is missing, so component traceability cannot resolve those ASR IDs.

A direct propagation of AssumedSystemRequirementsInfo through Feature Requirements fixes traceability, but causes an unintended documentation effect: the documentation generator treats the propagated provider as an owned ASR target and renders Feature Requirement content under the Assumed System section.

### Expected Changes of work products

- [ ] Requirements
- [ ] Architecture
- [ ] Safety Analysis
- [ ] Security Analysis
- [ ] Detailed Design
- [ ] Implementation and Testing
- [ ] all

### Impact analysis

NA

### Safety or Security relevance

- [ ] none
- [ ] Safety relevant
- [ ] Security relevant

### Expected required ASIL classification

QM

### Expected Implementation Version (Release)

1.0

Start by locating the Feature Requirement handling for derived_from and the component traceability processing that consumes AssumedSystemRequirementsInfo. Then inspect the documentation generator's handling of propagated providers. Done means referenced ASR IDs resolve during component traceability processing without rendering inherited Feature Requirement content as standalone Assumed System Requirement pages.

Written by the indexing model from the issue text.