fix: return errors instead of panicking on negative repeat counts and substr starts - #368

What

repeat and substr panic on negative numeric arguments:

• repeat passed its count straight to strings.Repeat, which panics on a negative count.
• substr checked end < 0, end < start, and start > len(str), but never start < 0, so any negative start panicked on the slice, in both the two-argument and three-argument forms.

Both reproduce through Engine.EvalExpr, the path nuclei uses to evaluate template expressions, and nothing on that path recovers panics, so one expression whose count or offset is computed from response data (an extracted length, len(...) - n) takes the whole scan down.

Fix

Return an error instead, mirroring the existing guards: "negative count" in repeat, "negative start position" in substr (next to the existing "negative end position"). Same approach as the recent aes_cbc bad-key/IV fix.

Regression tests in TestRepeatAndSubstrRejectNegativeArguments, following the TestAesCbcRejectsBadKeyAndIV idiom (require.NotPanics + require.Error).

Note: the four TestDslExpressions compression subtests (gzip/deflate/zlib/zip) fail identically on the base commit in my environment (Go 1.27 flate output differs from the pinned bytes); they are unrelated to this change.

Fixes #367