Different blocking for different devices: steps and client groups

Client groups put devices (addresses, networks, or ACLs of them) at a
blocking step: off (only your rules), normal (the default), or steps
added above it, each including the lists of the steps below. Lists
start at a step. In each view, a gate policy zone in front of a step's
lists lets the devices below that step through (rpz-client-ip triggers
with rpz-passthru), so every list is still loaded once. The IPv6 part
of a gate leaves the IPv4-mapped range out: named matches IPv4 clients
as ::ffff:a.b.c.d.

Web UI: a Devices panel on the Blocking page and a step on each list.
CLI: jarl block step, jarl block group, jarl blocklist --step. API:
/blocking/steps, /blocking/groups. Database schema 8.

Also: copying the state kept empty lists as empty (not nil), so
reverting a changeset no longer adds restore operations for unchanged
blocklists, rules and views.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

docs/validation.md

@@ -115,6 +115,11 @@ From [blocking.md](blocking.md).
 | `blocking_view_missing` | error | A list or rule names a view that doesn't exist |
 | `blocking_no_view` | warning | A list or rule applies to no view: none offers recursion, and blocking only changes recursive answers |
 | `blocking_no_recursion` | warning | A list or rule names a view that doesn't offer recursion, where it has no effect |
+| `blocking_step_missing` | error | A list or client group is at a step that doesn't exist (a list can't be at `off`) |
+| `client_group_member_invalid` | error | Client group members are addresses, networks, or ACLs made only of those |
+| `client_group_overlap` | error | The same address or network is in two client groups of a view |
+| `client_group_empty` | warning | A client group has no members |
+| `blocklist_step_unused` | warning | A list is at a step that no client group reaches, so it blocks nothing |
 
 ## Security lints