fix: reject a request body on a body-forbidden method (GET/HEAD/TRACE)

[OmarAlJarrah]

Problem

The Request model made body optional for every method and ran no method/body compatibility check, so a GET (or HEAD/TRACE) request carrying a body was publicly constructible. The two reference transports then handled that case inconsistently, and neither was correct:

• OkHttp passed the body to Request.Builder.method("GET", body), which throws IllegalArgumentException("method GET must not have a request body."). That unchecked exception escaped the transport's @Throws(IOException) contract and the retry pipeline.
• JDK built a BodyPublisher from the body and then called builder.GET(), which ignores it. The body was silently dropped — and for a small body the eager publisher path had already drained a consume-once writeTo into a byte array that was then discarded.

This is the inverse of the body-less POST/PUT/PATCH case fixed in #82: a body present on a method that forbids one, rather than a body absent on a method that requires one.

Change

Reject at construction, so the two transports never have to disagree:

• Method now carries a permitsRequestBody flag — false for GET, HEAD, TRACE, and CONNECT; true for the rest. The KDoc cites the relevant RFC 9110 sections.
• Request.RequestBuilder.build() throws IllegalArgumentException when a body is set on a method whose permitsRequestBody is false, with a message that names the method and points at the body-permitting alternatives.
• The JDK adapter now sends BodyPublishers.noBody() unconditionally for GET/HEAD/TRACE rather than adapting (and discarding) the body — there is no body to adapt, so nothing is consumed for nothing.
• The OkHttp adapter is unchanged in behavior; its KDoc now records that the crash path is unreachable because core rejects the body before dispatch.

Rationale

Failing fast at the model boundary is the single consistent policy: OkHttp can no longer receive a body it would crash on, and the JDK transport no longer consumes a single-use body it never sends. The error is raised once, at build time, with a clear message — rather than surfacing differently (or not at all) depending on which transport is wired in.

Public API

Two changes, both source- and binary-compatible:

• New Method.permitsRequestBody getter — the only change reflected in the sdk-core api snapshot (regenerated and committed).
• Request.RequestBuilder.body now accepts RequestBody? rather than RequestBody, so body(null) clears a body carried over by newBuilder() — the supported way to downgrade a body-carrying request to a body-forbidden method. Widening the parameter to nullable leaves the JVM descriptor unchanged, so it does not appear in the api snapshot and existing callers compile unchanged.

Tests

• sdk-core: build rejects a body on GET/HEAD/TRACE, allows it on POST/PUT/PATCH/DELETE/OPTIONS, allows a body-less forbidden method, and rejects a newBuilder that switches a body-carrying request to GET; plus a permitsRequestBody flag check in MethodTest.
• Both transport suites: symmetric tests that a body on a forbidden method is rejected before dispatch and that a body-less GET dispatches with no body. The OkHttp async-adaptation-failure test now triggers the failure via a non-http(s) URL scheme (which OkHttp rejects) since GET-with-body can no longer be built.

Gated build commands run (all passed)

• ./gradlew :sdk-core:test :sdk-core:ktlintCheck :sdk-core:detekt :sdk-core:apiCheck --no-daemon
• ./gradlew :sdk-transport-okhttp:test :sdk-transport-okhttp:ktlintCheck :sdk-transport-okhttp:detekt :sdk-transport-okhttp:apiCheck --no-daemon
• ./gradlew :sdk-transport-jdkhttp:test :sdk-transport-jdkhttp:ktlintCheck :sdk-transport-jdkhttp:apiCheck --no-daemon (detekt is skipped on this module)

Closes #117