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>

internal/api/types.go

@@ -506,6 +506,27 @@ type Blocklist struct {
 	// MemoryMB estimates what named needs for the list, in all its views.
 	MemoryMB int    `json:"memory_mb,omitempty"`
 	Pending  string `json:"pending,omitempty"`
+	// Step is the name of the step the list starts at ("normal" or one
+	// above it).
+	Step string `json:"step"`
+}
+
+// BlockStep is a blocking step above normal as returned by the API, with
+// what uses it.
+type BlockStep struct {
+	model.BlockStep
+	Lists   []string `json:"lists"`
+	Groups  []string `json:"groups"`
+	Pending string   `json:"pending,omitempty"`
+}
+
+// ClientGroup is a client group as returned by the API.
+type ClientGroup struct {
+	model.ClientGroup
+	Step      string   `json:"step"`
+	Views     []string `json:"views"`
+	AutoViews bool     `json:"auto_views,omitempty"`
+	Pending   string   `json:"pending,omitempty"`
 }
 
 // BlockRule is a block or allow rule as returned by the API.