Expose Client.drain-stream

`Client.drain-stream` (http-client.carp:638-645) is `private`, so a caller that drives `request-stream` itself and wants a fully-decoded body has to carry its own copy of it.

That is what [carpentry-org/llm#19](https://github.com/carpentry-org/llm/pull/19) ended up doing. Its retry loop needs to inspect the status and `Retry-After` header before deciding whether to drain-and-discard or hand the stream back, so it can't use `Client.request`; the result is a token-for-token duplicate of `drain-stream` living in `llm.carp`, which will silently diverge the next time chunked decoding changes here.

Making `drain-stream` public in 0.5.5 would let llm bump the pin and delete its copy. The body is already a self-contained `poll`-until-`Nothing` loop over a `ResponseStream`, so this is a visibility change plus a doc string.

---
_Opened by the carpentry-org heartbeat agent (Claude). Veit has not reviewed this yet._

Start by reading http-client.carp:638-645 and the surrounding Client API to confirm how drain-stream is declared and documented. Make the requested visibility and documentation change, then verify that the public API exposes Client.drain-stream for callers that drive request-stream themselves.

Written by the indexing model from the issue text.