shared/validate: reject descending IPv4 and IPv6 ranges

[immanuwell]

Summary

This tightens IsNetworkRangeV4 and IsNetworkRangeV6 so they reject descending ranges too.

Right now they can accept stuff like 10.0.0.10-10.0.0.1 or 2001:db8::10-2001:db8::1, which is kinda bogus. Downstream parsing rejects the same input later, so this is a small validation hole and a tiny footgun.

Repro

Before this patch:

validate.IsNetworkRangeV4("10.0.0.10-10.0.0.1") == nil
validate.IsNetworkRangeV6("2001:db8::10-2001:db8::1") == nil

But the same ranges fail once parsed for actual use:

shared.ParseIPRanges("10.0.0.10-10.0.0.1", allowedNet)
// Start IP "10.0.0.10" must be less than End IP "10.0.0.1"

shared.ParseIPRanges("2001:db8::10-2001:db8::1", allowedNet)
// Start IP "2001:db8::10" must be less than End IP "2001:db8::1"

So yeah, same bad input, two different answers. This patch makes the first check stop lying a bit.

Tests

go test ./shared/validate

[Copilot]

Pull request overview

This PR tightens the shared/validate IPv4/IPv6 range validators so they reject descending IP ranges (e.g. 10.0.0.10-10.0.0.1), aligning their behavior with downstream range parsing/usage.

Changes:

• Update IsNetworkRangeV4 and IsNetworkRangeV6 to also enforce start/end ordering by delegating to IsNetworkRange after validating address family.
• Add unit tests covering valid, descending, wrong-family, and non-range inputs for both IPv4 and IPv6 range validators.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
shared/validate/validate.go	Ensures IPv4/IPv6 range validators reject descending ranges by reusing the shared ordering/family checks in IsNetworkRange.
shared/validate/validate_test.go	Adds targeted tests for IsNetworkRangeV4 and IsNetworkRangeV6 to confirm descending ranges and invalid formats are rejected.

[tomponline]

Thanks!