Record that httpx.IntQuery parsed with fmt.Sscan, which reads as far as it can
and reports nothing about the rest, so "1e3" came back as 1, "0x10" as 16, "030"
as octal 24 and "50abc" as 50. Thirty handlers share that function, so every
bounded integer key this server publishes as `type: integer` with a minimum and
a maximum could answer a caller with a number it never sent.

Note that the parse is now strconv.Atoi and still trims surrounding spaces,
because a query string carries "+" as a space and "?days=+30" arrives as " 30" —
a stricter parse must not start refusing what clients legitimately send.

Record the opposite failure in expiringDays: its fallback is 0, and 0 is how the
contracts query says "do not narrow by end date", so an over-range value turned
the filter off rather than tightening it. get_expiring_contracts with days=5000
was answered with every contract in scope, including the ones carrying no end
date, and called them expiring.

Record that such a filter now clamps to its bound in the handler
(httpx.ClampQuery) and in the service (boundExpiringDays), so the REST and MCP
paths cannot drift apart, and that the OpenAPI description says so.

Record the six tests, including that an unreadable value has no side to be
pulled towards and still falls back, and that restoring the old parse makes them
fail. No migration; a caller sending decimal integers sees no change.