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/engine/engine.go

@@ -501,13 +501,15 @@ func (e *Engine) makePlan(ctx context.Context, base, work *model.State, user str
 	if len(work.Zones) != len(base.Zones) {
 		pl.configChanged = true
 	}
-	// Rules zones whose content changed. New ones come with a change to
-	// named.conf, and reconfig loads them.
+	// Rules zones and gates whose content changed. New ones come with a
+	// change to named.conf, and reconfig loads them.
 	for _, z := range pl.out.Policy {
 		if z.ListID != 0 || !changedPaths[z.File] {
 			continue
 		}
-		if slices.Contains(baseOut.Policy, z) {
+		if slices.ContainsFunc(baseOut.Policy, func(o render.PolicyZone) bool {
+			return o.Name == z.Name && o.ViewID == z.ViewID && o.File == z.File
+		}) {
 			pl.reloadPolicy = append(pl.reloadPolicy, z)
 		}
 	}