dotnet-trace Chromium conversion silently drops ActivitySource events

### Description

`dotnet-trace convert --format Chromium` silently produces an empty Chromium trace for a valid EventPipe trace containing `ActivitySource` spans bridged through `Microsoft-Diagnostics-DiagnosticSource`.

I first encountered this on a trace containing 1,432 `Activity/Start` events and 1,432 corresponding `Activity/Stop` events. A TraceEvent-based reader can enumerate those events and their payloads, but the converted file contains:

```json
{
"traceEvents": [],
"stackFrames": {}
}
```

The converter exits successfully and does not indicate that the activity events were omitted.

### Reproduction

Create `activity-repro.cs`:

```csharp
#:property PublishAot=false

using System.Diagnostics;

Activity.DefaultIdFormat = ActivityIdFormat.W3C;
Activity.ForceDefaultIdFormat = true;

using var source = new ActivitySource("ActivitySource.EventPipe.Repro");
using (source.StartActivity("Parent"))
{
using (source.StartActivity("Child"))
{
Thread.Sleep(100);
}
}
```

Collect and convert the trace:

```bash
dotnet-trace collect \
--providers 'Microsoft-Diagnostics-DiagnosticSource:0x3:5:FilterAndPayloadSpecs=[AS]ActivitySource.EventPipe.Repro' \
--format NetTrace \
--output activity-repro.nettrace \
-- dotnet activity-repro.cs

dotnet-trace convert --format Chromium activity-repro.nettrace
```

The `.nettrace` contains `Microsoft-Diagnostics-DiagnosticSource/ActivityStart` and `ActivityStop` events. The resulting `activity-repro.chromium.json` contains no trace events.

### Expected behavior

Ideally the converter would emit Chromium complete events or begin/end events for the activities, including their parent-child relationship.

If DiagnosticSource activities are intentionally unsupported by the Chromium converter, conversion should report that those events were omitted instead of silently producing a successful empty trace.

### Configuration

- `dotnet-trace`: `9.0.661903+d7b455b46332b31fd9ba3a3f3e020387984c511a`
- Runtime: `Microsoft.NETCore.App 11.0.0-preview.7.26360.111`
- OS: Ubuntu 24.04 under WSL2
- Architecture: x64

### Regression?

Unknown.

### Other information

The events can be recovered using a custom TraceEvent reader, so the EventPipe collection itself is successful. The current workaround is to parse `ActivityStart`/`ActivityStop` and their `Arguments` payload directly.

Related runtime behavior is being reported separately: the bridged events expose empty `TraceEvent.ActivityID` and `RelatedActivityID`, while their W3C identifiers are only present in the generic payload.

Start with activity-repro.cs and run the supplied dotnet-trace collect and convert commands to confirm the empty activity-repro.chromium.json output. Compare the ActivityStart and ActivityStop events in the .nettrace with the Chromium conversion result. Done means activities are emitted with their parent-child relationship, or conversion explicitly reports that they were omitted.

Written by the indexing model from the issue text.