--max-time accepts 0 and negative values without validation

[korya]

Problem

--max-time is converted straight to a duration and handed to http.Client.Timeout, where any value <= 0 means no timeout at all.

Reproduction

$ http-assert -m 0 --assert-ok http://127.0.0.1:8791/ok
[+] PASSED       ← no timeout applied

$ http-assert -m -5 --assert-ok http://127.0.0.1:8791/ok
[+] PASSED       ← no timeout applied

Why it matters

A user typing -m 0 most likely means "fail immediately", and a script computing a deadline that goes negative silently gets an unbounded request — the opposite of the intent, and a hang in CI.

Suggested fix

Reject negative values as an invalid argument. Either reject 0 too, or document explicitly that 0 disables the timeout (curl's convention).

[korya]

Sharper repro for the negative case — the timeout is not merely unvalidated, it is absent. Against an endpoint that sleeps 3s:

$ http-assert -m -5 --assert-ok http://127.0.0.1:8099/slow
[.] HTTP/1.1 GET http://127.0.0.1:8099/slow
[:] HTTP/1.1 200 OK
[+] PASSED 3.004270625s      ← 3s elapsed under a '-5 second' timeout

Worth noting the inconsistency with the sibling numeric flags, which validate and explain themselves well:

$ http-assert --retry -3 ...
Error: Invalid value for --retry flag: -3; it counts retries, so the smallest meaningful value is 0
$ http-assert -L --max-redirs -1 ...
Error: Invalid value for --max-redirs flag: -1; it counts redirects, so the smallest meaningful value is 0

--assert-status has the same gap, filed as #93.