Show multi-step test spans in class timeline, align report ordering with execution, and correlate linked OTel activities

[Copilot]

Multi-step DependsOn workflows were hard to follow in the HTML report because the class timeline excluded test-case spans, and the test list ordering could diverge from the span ordering. This updates the reporter to surface those per-step spans in the class timeline and present tests in execution order so BDD-style flows are easier to read.

This PR also fixes the missing OpenTelemetry activity correlation path for distributed flows that continue on a linked trace rather than the original test trace. Incoming OTLP spans that carry links to the test trace are now associated back to the owning test so they can appear in the report and correlate logs/output correctly.

• Class timeline

  • Stop filtering out test-case spans from the class-level waterfall.
  • Keep the timeline readable by collapsing synthetic test body spans and re-parenting their children to the test-case span.

• Execution ordering

  • Sort tests in each class by StartTime, then by name as a stable tie-breaker.
  • This keeps the visible test list aligned with the order shown in the timeline for chained DependsOn scenarios.

• OTel linked-trace correlation

  • Register derived OTLP traces back to the owning test when incoming spans include links to the original test trace.
  • Allow the activity collector to ingest external spans that are known via TraceRegistry, even if their trace IDs were not seen by the in-process listener first.
  • This covers async/distributed workflows where downstream processing starts a new trace but preserves causality through OTEL span links.

• Regression coverage

  • Add focused reporter tests for:
    • test ordering by execution start time
    • generated HTML containing the updated class timeline logic
  • Add focused OpenTelemetry tests for:
    • OTLP receiver ingestion of linked/derived traces
    • trace-to-test correlation for externally reported spans

Example of the kind of flow this makes visible in the class timeline:

[Test]
public Task SetupWiremock() => Task.CompletedTask;

[Test]
[DependsOn(nameof(SetupWiremock))]
public Task SendMessage() => Task.CompletedTask;

[Test]
[DependsOn(nameof(SendMessage))]
public Task VerifyWiremockWasCalled() => Task.CompletedTask;

With this change, those steps are rendered in the class timeline instead of being hidden behind suite-level spans only, and linked downstream OTel activities can now be attributed back to the triggering test.

[codacy-production]

Not up to standards ⛔

🔴 Issues 1 high · 2 minor

Alerts:
⚠ 3 issues (≤ 0 issues of at least minor severity)

Results:
3 new issues

Category	Results
Security	1 high
CodeStyle	2 minor

View in Codacy

🟢 Metrics 0 complexity

Metric	Results
Complexity	0

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}

[thomhurst]

@copilot read the latest comments on the issue. You haven't addressed the missing OTel activities.

[Copilot]

@copilot read the latest comments on the issue. You haven't addressed the missing OTel activities.

Addressed in ec211ae. The OTLP receiver now maps derived/linked traces back to the owning test when incoming spans carry links to the original test trace, and the activity collector now accepts registry-backed external traces so those activities show up in the report. I also added a regression test that posts a linked OTLP trace payload through /v1/traces to cover this path.