HTTP 300 from a target is silently treated as success

A job's owner relies on chronos to tell the truth about whether their webhook actually did what it was supposed to. If a target returns an ambiguous or redirect-class status code and chronos silently marks it "succeeded," the job's owner has no signal that something needs attention -- no retry happens, nothing shows up as dead, nothing gets logged as unusual. This erodes trust in a scheduler specifically: the system is up and confidently wrong, which is worse for on-call because there's no alert to respond to.

pkg/executor/executor.go's Execute classifies a response as successful with if resp.StatusCode >= 200 && resp.StatusCode <= 300. The upper bound is inclusive, so HTTP 300 (Multiple Choices) counts as success. The standard definition of the "2xx success" class is [200, 300) -- 300 itself belongs to the 3xx (redirection) class and should be treated as a failure like any other non-2xx response.

1. Stand up an HTTP server that responds 300 to any request.
2. Create a chronos job pointing at it, or call executor.New().Execute(ctx, job, runID) directly with job.TargetURL set to that server.
3. Observe Result.Success == true.

This is a classic off-by-one on a range boundary -- the kind of mistake that's easy to introduce in a one-character edit (< to <=) and easy to miss in review because "300" doesn't look obviously wrong next to "200" at a glance.

Compare the current condition against the standard definition of the 2xx status class. The fix is a single-character change to one comparison operator.