[Feature]: Extensibility for trace files

Nobody has claimed this yet.

### 🚀 Feature Request

We love using Playwright, and use it for quite some versatile use cases. Our majority of tests consists of API tests. However, we also have a big set of Event based tests (e.g. Apache Pulsar), and occasionally a mainframe based test.

Currently, the trace files only contain the Playwright-native methods that are being called. So for example, the before and after hooks, the steps, the test itself, the fixtures, the HTTP calls made, the expects that have been called, ...

Where we're losing out on tracing though is in our Event based tests. We're still using the Playwright test runner for that, and in some tests we even perform some HTTP calls to trigger certain conditions. However, currently, only those HTTP calls are included in the traces, and there's no simple way for us to add information to the trace file with actions that have occurred like "Send event", "Receive event".

I'm aware that the `test.info().annotations.push()` function exists, but that doesn't suffice for our case.

Ideally, I'd like to be able to extend the reported actions in the Trace viewer, so that when I call a function, for example `pulsar.send()`, that function can hook into the reporting API, and can report a title, for example `send event "tenant/namespace/topic"` and that I can then click on that in the trace viewer, and in the `Call` tab, that I can see the parameters I sent to that "send event" call, and what the return value was for example.

### Example

```typescript
export const sendEvent = () => {
const return = ... // do the necessary calls to send an event; not relevant for this example

test.info().action({ title: `send event "tenant/namespace/topic"`, parameters: { x: "test", y: false }, return: return })
}
```

### Motivation

Playwright's test runner is an excellent foundation for many types of integration testing, not just browser automation. Its fixture system, parallel execution, retry logic, and rich reporting make it a natural choice even for teams whose primary test surfaces are REST APIs, event-driven systems, or even mainframes.

However, the trace viewer currently only captures Playwright-native instrumentation: hooks, steps, fixtures, HTTP calls via request, and expect calls. As soon as you integrate a non-Playwright client, for example an Apache Pulsar consumer/producer, a raw TCP connection, a mainframe terminal emulator, those interactions become invisible in the trace. The trace shows a gap where the most interesting work happened.

test.info().annotations.push() exists, but it is a blunt instrument: it adds a flat label to the test, not a structured, time-ordered entry in the action timeline. It cannot capture parameters, return values, or timing, and it does not appear inline in the call sequence where the action actually occurred.

The result is that traces for non-browser tests are difficult to use for debugging. A failing event-driven test might show the HTTP setup call that preceded it, then nothing, then a timeout assertion, with no visibility into whether the event was sent, whether a response was received, or what the payload looked like.

A lightweight API to push structured entries into the trace timeline, with a title, optional parameters, and an optional return value, would make Playwright traces genuinely useful across the full breadth of test types the runner already supports. It would also allow library authors (Pulsar clients, database drivers, gRPC stubs, etc.) to ship first-class Playwright trace integration without requiring changes to Playwright core beyond the hook itself.

Start with the test.info() entry points and the trace viewer's action timeline and Call tab. Determine how Playwright-native actions are recorded and rendered, then compare that flow with the proposed test.info().action() inputs for titles, parameters, and return values. Done means externally generated actions appear in order with their associated details in the trace viewer.

Written by the indexing model from the issue text.