Transport header-drop logs at WARN per request may be noisy for repeated non-encodable headers #168

Context

In #140 the request adapters in sdk-transport-okhttp and sdk-transport-jdkhttp now catch the transport's unchecked IllegalArgumentException when a model-valid header cannot be encoded by that transport (e.g. a non-ASCII name/value) and drop the header instead of letting the exception escape execute()'s @Throws(IOException) contract. That drop is logged at WARN (raised from verbose) so the silent header loss is visible to operators.

Problem

The drop log fires per header, per request. A caller on a hot path that repeatedly sets the same non-encodable header would emit a WARN on every call — potentially high-volume, low-signal noise. This is easy to hit on OkHttp, which rejects all non-ASCII names/values.

Note this only affects the unexpected-drop path: the known restricted-header pre-drops (Connection, Host, Content-Length, etc.) correctly stay at verbose.

Decision needed

Decide the right balance between visibility and noise, e.g.:

• Keep WARN as-is — every drop is a header the caller explicitly set and did not get on the wire, which is arguably always worth surfacing.
• De-duplicate to once per distinct (transport, header-name) so the warning surfaces once rather than on every request.
• Emit at a lower level with a single aggregated or first-occurrence warning.

References

Behavior introduced in #140 (RequestAdapter.attachHeaders / RequestAdapter.adapt in both transports).