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

@@ -304,6 +304,28 @@ CREATE TABLE blocklist_status (
 	// 7: disabled zones, kept but not loaded by named.
 	`
 ALTER TABLE zones ADD COLUMN disabled INTEGER NOT NULL DEFAULT 0;
+`,
+	// 8: blocking steps and client groups (docs/blocking.md).
+	`
+ALTER TABLE blocklists ADD COLUMN step_id INTEGER NOT NULL DEFAULT 0;
+CREATE TABLE block_steps (
+	id INTEGER PRIMARY KEY,
+	name TEXT NOT NULL,
+	position INTEGER NOT NULL DEFAULT 0,
+	comment TEXT NOT NULL DEFAULT '',
+	version INTEGER NOT NULL, created_at TEXT NOT NULL, updated_at TEXT NOT NULL,
+	created_by TEXT NOT NULL DEFAULT '', updated_by TEXT NOT NULL DEFAULT ''
+);
+CREATE TABLE client_groups (
+	id INTEGER PRIMARY KEY,
+	name TEXT NOT NULL,
+	members TEXT NOT NULL DEFAULT '[]',
+	step_id INTEGER NOT NULL DEFAULT 0,
+	view_ids TEXT NOT NULL DEFAULT '[]',
+	comment TEXT NOT NULL DEFAULT '',
+	version INTEGER NOT NULL, created_at TEXT NOT NULL, updated_at TEXT NOT NULL,
+	created_by TEXT NOT NULL DEFAULT '', updated_by TEXT NOT NULL DEFAULT ''
+);
 `,
 }