Question: could Think expose messenger concurrency configuration?

Hi! We’re using `@cloudflare/think` with `chatSdkMessenger()` for a multi-user Slack integration and noticed that `ThinkMessengerRuntime` currently creates its `Chat` instance with a hardcoded concurrency policy:

```ts
concurrency: {
debounceMs: 600,
strategy: "burst",
}
```

We’re curious whether there’s a reason this is fixed rather than exposed through Think’s messenger configuration.

In our case, two different users can post in the same Slack thread within that 600ms window. The underlying Chat SDK retains the earlier message in `MessageContext.skipped`, but Think’s registered handlers don’t consume or forward that context. As a result, only the latest message reaches `chatWithMessengerContext()`.

We’d prefer independent `concurrent` dispatch because each message carries a different user identity and authorization context. Combining skipped messages into the latest user’s turn would be unsafe for us.

The underlying `chat` package already supports what we need:

```ts
concurrency: {
strategy: "concurrent",
}
```

But `ChatSdkMessengerOptions` doesn’t currently expose that setting. We’ve temporarily applied a version-pinned package patch, though we’d much rather use a supported typed option.

Would you be open to exposing concurrency configuration through Think, perhaps at the messenger-runtime level?

```ts
chatSdkMessenger({
// ...
concurrency: {
strategy: "concurrent",
maxConcurrent: 10,
},
})
```

A few questions:

- Is `burst` intentionally fixed because Think’s fiber or delivery model assumes serialized handlers?
- Is there already a supported configuration path we’ve missed?
- Since one `Chat` instance can host multiple adapters, would you prefer concurrency to be configured globally rather than per messenger?
- Is there a recommended lossless, bounded strategy for multi-user threads?

We’ve observed this with `@cloudflare/think@0.12.1` and confirmed that `0.13.0` appears to retain the same hardcoded policy.