#894 serve: decode chunked request bodies (fixes empty-body 400 behind some proxies)

Description

Fixes #893.

POST handlers in `serve/server.py` read the body via `Content-Length` only:

```python
self.rfile.read(int(self.headers.get("Content-Length", 0)))
```

A proxy/relay forwarding a request with `Transfer-Encoding: chunked` instead (no `Content-Length` — valid per RFC 7230, common when a proxy streams a body of unknown length) gets read as 0 bytes, so the JSON parses empty and the API returns a misleading `400 "No messages provided"` instead of actually seeing the request. Repro and details in #893.

**Change:** adds a `_read_body()` helper on the request `Handler` that reads via `Content-Length` as before, or decodes a chunked body (`<size-hex>\r\n<data>\r\n` segments until the terminating `0`-size chunk) when `Transfer-Encoding: chunked` is present instead. Used in `do_POST`'s main dispatch, which covers `/v1/chat/completions`, `/v1/messages`, and the other `/v1/*` routes.

**Scope:** kept minimal/targeted at the reported bug. Three other spots (`_control_body` for `/unload` and `/load`, `_config_post`, `_settings`) read bodies the same Content-Length-only way and would benefit from the same helper for consistency — left alone here since they're for the local web UI, not the API path that was actually broken; happy to extend this PR to cover them too if maintainers want it in the same change.

**Testing:**
- `python3 -m py_compile serve/server.py` passes
- Verified locally: a `Transfer-Encoding: chunked` request to `/v1/chat/completions` returned 400 before this change, 200 after, with an identical response body to the equivalent `Content-Length` request
- Verified against a real relay (a proxy that tunnels requests over a WebSocket and re-issues them locally without a precomputed `Content-Length`): requests that previously failed 400 now succeed end-to-end