fix(data): respect caller Content-Type; clean up source comments

[wenchy]

Summary

A doc-cleanup pass surfaced a real regression, which is fixed here alongside the comment work.

Behavior fix — Content-Type handling

Since 13db74d (auto-deduce content type), requestData unconditionally ran opts.Headers.Set("Content-Type", ...), overwriting any Content-Type the caller set via Headers/HeaderPairs. Pre-13db74d, Data never touched Content-Type, so Data(x) + a custom Content-Type worked. This restores that capability for Data.

The split is now principled — based on whether the body format is known or guessed:

Option	Body format	Content-Type
Data	deduced (guessed)	respects a caller-supplied value; deduces only when unset
JSON / Form / Files	known (marshal/encode/multipart)	forces (overrides any caller value)

Form/Files must force because their Content-Type carries the boundary the body depends on. JSON forces for the same reason the body format is known — and because custom JSON media types (application/ld+json, application/problem+json, …) are already covered by Data + an explicit Content-Type (Data marshals structs/maps via json.Marshal just like JSON). So only Data needs to defer to the caller.

Net behavior delta vs master: only Data changes (regains override support). JSON/Form/Files keep their existing force behavior.

Comment cleanup across source files

Standardized doc comments for clarity/conciseness (wraps [http.X], sends an HTTP GET request, sets/forces Content-Type to, etc.) and corrected a few misleading comments. The Data comment now accurately describes deduceContentTypeAndBody's real evaluation order (io.Reader first, then pointer deref, then kind rules), the *[]byte raw-bytes case, and the typed-nil-pointer ((*T)(nil) → "<nil>") footgun.

Files

request.go, options.go, response.go, client.go, method.go, interceptor.go, default.go, request_test.go

Verification

• go build ./... ✅
• go vet ./... ✅
• go test ./... ✅ — including TestContentTypeOverride: Data deduces when unset and respects a caller value; JSON/Form force their Content-Type.

🤖 Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 83.19%. Comparing base (c3ec67b) to head (908249b).

Additional details and impacted files

@@            Coverage Diff             @@
##           master      #51      +/-   ##
==========================================
+ Coverage   83.05%   83.19%   +0.14%     
==========================================
  Files           7        7              
  Lines         360      363       +3     
==========================================
+ Hits          299      302       +3     
  Misses         38       38              
  Partials       23       23              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[wenchy]

Follow-up tying this work to #48: issue #48's two-case model (caller-supplied Content-Type wins; otherwise deduce from type) is now both implemented and documented.

• Case 1 (caller supplies Content-Type): was broken on master — requestData unconditionally overwrote it. Fixed here via setContentTypeIfAbsent, so a Headers/HeaderPairs Content-Type now wins for Data.
• Case 2 (no Content-Type): unchanged type-based deduction.
• Data: handle any type gracefully based on "Content-Type" of headers #48's equivalence test (Data(string) == Data([]byte) for the same content) is now pinned by TestDataStringVsBytesEquivalent — verified to pass (both yield text/plain; charset=utf-8 + identical body).
• Data/Body doc comments and a README example spell out the two cases and the sniff heuristic caveat (XML → text/xml/text/plain, so set application/xml explicitly).

Refs #48.