Track Content-Length as a Long so bodies past 2 GiB stream

[hellerve]

0.9.2 refused any `Content-Length` over 2147483647 with `ClientError.Parse`, so a download past 2 GiB could not go through `request-stream` at all. Lengths are now read and tracked as a `Long`.

• `ResponseStream.remaining` is `(Maybe Long)` (was `(Maybe Int)`). Its type is the one public change. llm passes `(Maybe.Nothing)` in that slot, which still type-checks.
• `parse-length` accepts up to 9223372036854775807 and still refuses anything larger instead of wrapping. The bound is a literal, not `Long.MAX`: core registers that as C's `LONG_MAX`, which is 32 bits on armhf and Windows, while `Long` is `int64_t`.
• Tests: 2147483648 and 4294967301 are now lengths, as is the int64 maximum. One past it and a value that wraps to a small `Long` are rejected. The three new length assertions failed before the change.
• README: states the limit as a number and notes that HEAD, 1xx, 204 and 304 responses skip the check, as Frame Content-Length bodies per RFC 9112 §6.3 #29's review suggested.