Affected: npm: nodemailer

### Summary

When `addressparser` finds no address by its strict reading, it falls back to pulling one out of the free text with `/\s*\b[^@\s]+@[^\s]+\b\s*/`. That pattern backtracks quadratically: `[^@\s]+` is retried from every offset and rescans the run to the next `@` each time. A single header value holding a long whitespace-free run with no usable `@` blocks the Node.js event loop for tens of seconds.

It is cheaper to exploit than GHSA-prgh-xp8r-p3m5: 273KB is enough for ~43s, where the comment-joined shape needed ~1.5MB for ~10s.

### Details

The fallback in `src/addressparser/index.ts` ran the pattern as a search. `[^@\s]+` crosses neither whitespace nor `@`, so from each start offset it scans forward to the next `@` or to the end of the run and then fails, and the engine simply advances one character and repeats. Three shapes make every offset fail:

- the run holds no `@` at all - the only `@` has nothing after it - the only `@` has nothing before it

A fourth reaches it with a valid address present but placed past a long run, so the long run is walked before the match is found.

### PoC

```js const addressparser = require('nodemailer/lib/addressparser'); const s = Date.now(); addressparser(' >' + '>[x][x]'.repeat(40000)); // 273KB console.log(Date.now() - s, 'ms'); // ~43000 ms, blocking ```

Measured on 10.0.5:

| Value | Parse time | | --- | --- | | `'[x]'.repeat(40000)` (117KB) | 9.0 s | | `'[x]'.repeat(40000) + '@'` (117KB) | 8.9 s | | `'@' + '[x]'.repeat(4…