Internal Go and library error strings leak into user-facing messages

[korya]

Problem

Several error paths surface raw Go or third-party library strings. They sit next to messages that are unusually well written, which makes the contrast sharp.

Input	Message
--assert-status notanumber	strconv.ParseInt: parsing "notanumber": invalid syntax
HTTP_ASSERT_MAX_TIME=abc	strconv.ParseInt: parsing "abc": invalid syntax
--assert-jq against a non-JSON body	body: expected JSON, got invalid character 'h' in literal true (expecting 'r')
-X 'BOGUS METHOD'	net/http: invalid method "BOGUS METHOD"

The jq one is the most damaging. Against a body of this is not json at all, Go's decoder reports in literal true (expecting 'r') because the body starts with t. A user reads that and goes looking for a true they never wrote — the message actively misdirects.

Reproduction

$ http-assert --assert-jq '.status=="ok"' http://127.0.0.1:8099/notjson
Error: 1 assertions failed:
- body: expected JSON, got invalid character 'h' in literal true (expecting 'r')

Why it matters

The tool's own voice is good — Invalid value for --retry flag: -3; it counts retries, so the smallest meaningful value is 0, or no decoder for "exotic-9000"; br, deflate, gzip, zstd are supported. The leaked strings read as a different program.

Suggested fix

Wrap these the way the good messages are wrapped. For the JSON case, say what was actually wrong — that the body is not JSON — and show a short prefix of it, rather than forwarding the decoder's byte-level complaint.

Related: #26 (--maphost discards its own parse error).