Reject negative parameter steps before expanding ranges

[Likio3000]

Reject negative --parameter-step-size values before expanding a range, preventing small invalid integer scans from growing until memory allocation fails. Report a clear error and document that the step must be positive.

AI disclosure: prepared and tested with Codex (GPT-6 Astra, model label supplied by the user).

Before and after

Reproduction and implementation

On upstream master (0f7ae35), this invalid scan starts generating echo 0, echo -3, echo -6, … instead of rejecting the negative step:

hyperfine --runs=1 -P n 0 1 --parameter-step-size=-3 'echo {n}'

RangeStep::new rejects zero steps but not negative ones. Integer division in the size estimate rounds (1 - 0 + 1) / -3 to zero, so the scan passes the size limit. Command construction then keeps appending values moving away from the upper bound. Under a 256 MiB address-space limit, both debug and release builds aborted with a memory allocation failure before running a benchmark. The single-value range -P n 0 0 --parameter-step-size=-2 reproduces the same problem.

The added check returns Parameter step size must be positive before calculating the range size. Decimal negative steps get the same actionable diagnostic, replacing the misleading Parameter range is too large error. Zero-step behavior is preserved. The CLI help and man page state the positive-step requirement.

This complements the positive-step overflow fixes proposed in #921 and #930; neither rejects negative steps in range construction.

Validation

Linux, Rust 1.97.0:

• Added integer and decimal constructor regressions, both confirmed failing against the original implementation. These test validation without expanding a runaway range.
• Added a CLI regression for the error message and exit status.
• cargo test --locked --offline: 108 passed.
• cargo fmt -- --check and cargo clippy --locked --offline --all-targets: passed.
• cargo build --locked --offline --release: passed.
• Repeated the bounded CLI reproductions: debug and release builds now exit with code 1 and the expected error.
• Real CLI benchmarks with positive integer/decimal steps and negative bounds still produce the expected commands, valid JSON, and successful exit codes. Zero steps still receive the original error.

[sharkdp]

Thank you