parseRange split the spec on '-' and required BOTH bounds to parse as
integers. For a valid open-ended range like '5-' (RFC 3977 6.2.3 / RFC 2980
XOVER: article 5 through the last) strconv.ParseInt('') fails, so parseRange
returned (0, 0) and handleOver asked the backend for articles in [0, 0] —
zero rows. '-10' (first..10) was likewise broken.
Treat an empty bound as the extreme (low 0 / high MaxInt64) while still
returning an empty range for genuinely malformed specs. Add table-driven
tests for the open-ended and malformed forms.
parseRange previously returned (0, MaxInt64) for unparseable input,
causing OVER/XOVER to deliver the full article overview instead of
returning an empty result. Now returns (0, 0) for any parse error.
Fixes#45
Co-authored-by: root <root@vultr.guest>
