ethers-v6: wrong type generated for listening to contract events

I've generated the types for an ERC20 contract with ethers-v6. I would like to listen to the transfer events, to that end I call

```
token.on(token.filters.Transfer(), async (...args) => {
const lastArg = args[args.length - 1];
console.log(lastArg)
// do something with it
}
```

The generated types claim lastArg to be of type:
```
lastArg: TypedEventLog> | undefined | string | bigint
```

However, the console.log gives me the following output:
```
ContractEventPayload {
filter: PreparedTopicFilter {
fragment: EventFragment {
type: 'event',
inputs: [Array],
name: 'Transfer',
anonymous: false
}
},
emitter: Contract {
target: '0x...',
interface: Interface {
fragments: [Array],
deploy: [ConstructorFragment],
fallback: null,
receive: false
},
runner: Wallet {
provider: [InfuraProvider],
address: '0x...'
},
filters: {},
fallback: null,
[Symbol(_ethersInternal_contract)]: {}
},
log: EventLog {
provider: InfuraProvider {
projectId: '...',
projectSecret: ...
},
transactionHash: '0x...',
blockHash: '0x...',
blockNumber: ...,
removed: false,
address: '0x...',
data: '0x...,
topics: [
'0x...',
'0x...',
'0x...'
],
index: 12,
transactionIndex: 6,
interface: Interface {
fragments: [Array],
deploy: [ConstructorFragment],
fallback: null,
receive: false
},
fragment: EventFragment {
type: 'event',
inputs: [Array],
name: 'Transfer',
anonymous: false
},
args: Result(3) [
'0x...',
'0x...',
10000n
]
},
args: Result(3) [
'0x...',
'0x...',
10000n
],
fragment: EventFragment {
type: 'event',
inputs: [ [ParamType], [ParamType], [ParamType] ],
name: 'Transfer',
anonymous: false
}
}
```

The `TypedEventLog<...` object is actually found under `lastArg.log` instead of `lastArg` itself being of type `TypedEventLog<...`

Checking the [ethers documentation](https://docs.ethers.org/v6/getting-started/#starting-contracts) under "Listening to Events" it says that

> There is always one additional parameter passed to a listener, which is an [EventPayload](https://docs.ethers.org/v6/api/utils/events/#EventPayload), which includes more information about the event including the filter and a method to remove that listener.

Which seems to line up with the behaviour I am observing