`ConcurrencyConfig.max_concurrent` is unused — enforce it per upstream

[patrick-chinchill]

Latent bug — config field silently ignored.

The bug

ConcurrencyConfig.max_concurrent is accepted from user config and assigned to self._concurrency_max_concurrent in `Chat.init` at `src/chat_sdk/chat.py:280,287,295`, but no code reads that field anywhere. Users setting `max_concurrent=5` expect a 5-way semaphore and get unlimited concurrency.

```bash
$ grep -n 'max_concurrent|_concurrency_max_concurrent' src/chat_sdk/chat.py
280: self._concurrency_max_concurrent: int | None = None
287: self._concurrency_max_concurrent = None
295: self._concurrency_max_concurrent = concurrency.max_concurrent
```

Three writes, zero reads.

Upstream behavior

Upstream TS uses it as a semaphore limit for the `"concurrent"` strategy:

• `vercel-chat/packages/chat/src/chat.ts:269,278,288` — defaults to `Number.POSITIVE_INFINITY`
• `vercel-chat/packages/chat/src/types.ts:711` — field on `ConcurrencyConfig`

Fix

1. Add an `asyncio.Semaphore` initialized to `max_concurrent` (or bypass if `None` / infinity) in `Chat.init`
2. Acquire it in the `"concurrent"` strategy path before dispatching handlers
3. Release on completion/error
4. Regression test: 10 concurrent messages with `max_concurrent=2` should serialize into 5 pairs

Impact

• chinchill-api uses `concurrency="drop"`, unaffected today
• Other consumers with `concurrency=ConcurrencyConfig(strategy="concurrent", max_concurrent=N)` silently get unlimited concurrency

Acceptance

• `max_concurrent` actually bounds concurrent dispatches
• Regression test proves the bound holds under load
• Behavior matches upstream (defaults to unlimited when `None`)

[patrick-chinchill]

Re-checked against upstream TS — upstream also doesn't enforce `maxConcurrent`.

```
$ grep -rn 'maxConcurrent' vercel-chat/packages/chat/src/
types.ts:711: maxConcurrent?: number;
chat.ts:269: maxConcurrent: Number.POSITIVE_INFINITY,
chat.ts:278: maxConcurrent: concurrency.maxConcurrent ?? Number.POSITIVE_INFINITY,
chat.ts:288: maxConcurrent: Number.POSITIVE_INFINITY,
```

3 writes, 0 reads — exact same pattern as Python. `handleConcurrent` in TS just calls `dispatchToHandlers` directly with no semaphore gating.

Revised severity: This is not a Python regression or silent correctness bug vs upstream. Both codebases silently accept `max_concurrent=N` and run unlimited. It's a genuine unused-config-field gap that should be either:

1. Implemented on both sides (Python leading) — adds a real bound
2. Removed from the config type — simpler, honest about the current behavior

I'd recommend option 1 for consumers who actually need the bound, but it's a Python-specific enhancement rather than parity work. No longer blocking the 0.4.26.1 release.