Subnet filter parity — ranges on the fleet miner-list page + native ip_ranges backend

[flesher]

Context

The rack-placement subnet filter (Search / Manage miners modals) now accepts IP ranges — short (10.0.0.10-20) and full (10.0.0.10-10.0.0.20), matching the onboarding network discovery input syntax. Ranges are decomposed to their minimal covering CIDRs client-side and sent over the existing MinerListFilter.ip_cidrs field (Postgres containment). Shipped in #673.

Two gaps remain for full parity across the three subnet-input surfaces (network discovery, rack subnet filter, fleet miner-list page filter):

1. The main /fleet miner-list filter still accepts CIDR/IP only — no ranges.
2. Because MinerListFilter has no range field, ranges are represented as decomposed CIDRs. On the fleet page (which persists the filter to the URL) a shared/bookmarked range reloads as its CIDR set rather than the range.

Part A — client: ranges on the fleet miner-list filter

• MinerList.tsx: swap subnetFilter from validateCidrLine/normalizeCidrLine to the shared validateSubnetLine/normalizeSubnetLine; add a range example to the placeholder; expand via expandSubnetLineToCidrs at the RPC build (MinerList.tsx:~1072).
• filterUrlParams.ts: accept ranges on decode (:~379, :~411) using validateSubnetLine/normalizeSubnetLine, and preserve the range string in the URL rather than the expanded CIDRs.
• Update filterUrlParams.test.ts.

Known caveat without Part B: since the proto only carries ip_cidrs, any encode path that goes through the proto filter can't represent a range, so a reloaded range renders as its CIDR set. The single subnet chip flips from e.g. 10.0.0.10-10.0.0.21 to "4 subnets" (typical small ranges expand to ~4–14 entries; absolute worst case for an IPv4 range is 62). Same miners matched — noisier chip/editor. Part B removes this.

Part B — backend: native ip_ranges on MinerListFilter (the clean fix)

• Add repeated IpRange ip_ranges (start/end) to MinerListFilter; server SQL matches ip_address_inet BETWEEN start AND end, OR'd across entries, AND'd with other facets. Regen Go/TS/SDK.
• Client stops decomposing — ranges live natively through ActiveFilters → proto → URL, eliminating the Part A caveat and making the filter's server contract shaped like discovery's native ranges.
• Not required for correctness — CIDR decomposition already matches identical miners; this is for clean range representation + wire-format symmetry with discovery.

Explicitly out of scope

• Hostnames on filters. Discovery resolves hostnames via DNS to scan; a filter matches existing miners by IP (ip_cidrs) with no hostname to match against (there's no DNS in-browser and no name/hostname field server-side). The rack filter already rejects hostnames with a targeted message. This stays discovery-only by design.

Related

• Follows Multi site: improve Search miners modal — robust filters + include/exclude ineligible toggle #673 (rack-placement filters + assignable-only toggle + range-capable subnet filter).
• The separate name-search facet (free-text match on miner name — the #673 "name filter" deferred to sort) is a distinct follow-up: its own name_query field + server ILIKE/trigram + a dedicated "Name" facet, not folded into the subnet box.

🤖 Generated with Claude Code