fix(http-client): set application/json on body + use JdkClientHttpRequestFactory for PATCH (v3.0.1)

[jlc488]

Summary

Two real bugs in core's HTTP client utilities — both surfaced by the first end-to-end consumer (devslab-examples `api-log-{jpa,mybatis,r2dbc}-demo` set) calling `postSyncTyped` against a real `@RequestBody`-annotated controller. Plus 65 new end-to-end test cases (4 new IT classes) so any future regression of this class is caught immediately.

Bugs fixed

1. `Content-Type` missing on POST/PUT/PATCH bodies

`RestClient.body(String)` / `WebClient.bodyValue(String)` route the body through `StringHttpMessageConverter`, which writes `Content-Type: text/plain;charset=ISO-8859-1` by default. Any downstream service binding with `@RequestBody Foo` rejected the call as Unsupported Media Type → 415 → propagated as 500 to the test client.

Fix: both `exchange()` methods explicitly set `MediaType.APPLICATION_JSON` when a payload is present.

```diff

• return spec.body(payload).retrieve();

• return spec.contentType(MediaType.APPLICATION_JSON).body(payload).retrieve();
  ```

2. `patchSync*` / `patchAsync*` broken end-to-end

`RestApiClientAutoConfiguration` wired `SimpleClientHttpRequestFactory` (backed by `java.net.HttpURLConnection`), whose `setRequestMethod` throws:

```
java.net.ProtocolException: Invalid HTTP method: PATCH
at java.base/java.net.HttpURLConnection.setRequestMethod(...)
```

A long-standing JDK limitation. `patchSync` was a published API that could never actually run.

Fix: swap to `JdkClientHttpRequestFactory` (`java.net.http.HttpClient` backed, Java 11+). All five verbs supported natively; `read-timeout` preserved; `connect-timeout` default left to `HttpClient` (consumers who need tighter swap the bean — it's `@ConditionalOnMissingBean`).

Why these escaped CI before

`RestApiClientUtilRoutingTest` / `ReactiveApiClientUtilRoutingTest` are subclass-recording mocks that intercept `send` / `sendTyped` before `exchange()` runs. They verify "POST was called with these args" but never reach the HTTP layer. Bug 1 is invisible above `exchange()`; bug 2 needs `setRequestMethod` to be called.

The gap was: no test that hit an actual socket or actual `@RequestBody`.

Test coverage added (65 cases, 4 classes)

Class	Layer	What it pins
`RestApiClientUtilWireIT`	MockWebServer wire-level	`Content-Type` per body-carrying verb, exact body bytes, UTF-8 encoding (Korean + emoji), 32 KB bodies, HTTP method propagation, no leakage of internal `requestId` to wire headers, async path
`ReactiveApiClientUtilWireIT`	Same, for WebClient	Reactive mirror of the above
`RestApiClientUtilSpringE2EIT`	`@SpringBootTest` (servlet) + `@RequestBody Foo`	Real Tomcat round-trip for all 5 verbs, 4xx/5xx propagation, Unicode + nested + null-field bodies, async
`ReactiveApiClientUtilSpringE2EIT`	`@SpringBootTest` (reactive) + `@RequestBody Mono`	Real reactor-netty round-trip, same coverage

Both E2E ITs pin `spring.main.web-application-type` explicitly because the test classpath has both `spring-boot-starter-web` and `spring-boot-starter-webflux` and the default would pick servlet for the reactive one too.

The E2E ITs also register a no-op `ApiLogWriter` bean — `ApiEventListener` requires the SPI to wire up, but writer implementations live in `:jpa` / `:r2dbc` / `:mybatis`. Documented inline in each test class.

Compatibility

• No public API changes. All `RestApiClientUtil` / `ReactiveApiClientUtil` method signatures unchanged. Drop-in upgrade from 3.0.0.
• Behaviour change for raw non-JSON String bodies. Before 3.0.1, raw String payloads went out as `text/plain`. After 3.0.1, every body-carrying call sends `application/json`. If you genuinely need another content type for an outbound call, use Spring's `RestClient` / `WebClient` directly — api-log's wrappers are explicitly JSON-only by design (JSON + JSONB-centric library).
• `ClientHttpRequestFactory` bean swap. Any consumer that supplied their own factory via `@ConditionalOnMissingBean` continues to win; only the default changed.

Upgrading from 3.0.0

```diff

• implementation("kr.devslab:api-log-core:3.0.0")

• implementation("kr.devslab:api-log-core:3.0.1")

• implementation("kr.devslab:api-log-jpa:3.0.0")

• implementation("kr.devslab:api-log-jpa:3.0.1")

• implementation("kr.devslab:api-log-r2dbc:3.0.0")

• implementation("kr.devslab:api-log-r2dbc:3.0.1")

• implementation("kr.devslab:api-log-mybatis:3.0.0")

• implementation("kr.devslab:api-log-mybatis:3.0.1")
  ```

Recommended for anyone on 3.0.0 — every consumer calling a body-carrying method against a real Spring service is affected.

Test plan

• CI green (4 new IT classes added to `:core:test`)
• Manually re-run devslab-examples PR #62 with `api-log-*:3.0.1` to verify the previously failing `postBodyIsPreservedInPayloadColumn` tests now pass

Downstream actions after merge + v3.0.1 tag

• devslab-examples PR #62 — bump 3 demos' `api-log-*:3.0.0` → `:3.0.1` (one line per build.gradle.kts × 3 = 3 line edits)
• Profile README — no badge change needed; the api-log badge uses no version filter so it auto-tracks