feat: harden firewall policies telemetry and operations

Implement reliable agent apply, telemetry v2, analytics retention, guarded rollouts, enrollment, labels and webhooks. Improve ReUI frontend data safety and bounded list loading, and add Docker smoke, recovery and resource checks. Document local verification and pending native acceptance.

docs/list-import-summary.md

@@ -0,0 +1,21 @@
+# Bounded list import response
+
+`POST /api/v1/lists/:id/entries?return=summary` opts into a bounded response:
+
+```json
+{"count":100000,"content_hash":"sha256:...","changed":true}
+```
+
+`count` is the total stored effective CIDR count after publication. `content_hash` is the stored content hash; `changed` records whether the root list's effective memberships changed. The response is derived from a SQL count and hash projection and does not serialize stored rows, source config or full list detail.
+
+The opt-in path accepts a fully duplicate valid import as a successful no-op with `changed:false`, preserving agent generations. Mixed valid/invalid input still rejects the entire request before publication. With no query parameter the existing full-detail success response and duplicate-import error behavior remain unchanged. The existing 100000-entry and 8 MiB import bounds apply to both modes.
+
+The frontend import/delete mutations use summary responses and invalidate list queries. `DELETE /lists/:id/entries?return=summary` returns the same summary after atomic deletion. Default delete responses remain full details.
+
+`GET /lists/:id?view=page&limit=100&offset=0` opts into SQL pagination (limit 1–200, offset 0–10000000). Without query parameters the legacy full detail remains available. Invalid paging/filter parameters reject the request instead of falling back to the full response. Paged responses contain metadata, bounded `items` and preview `entries`, total stored `entry_count`, filtered logical-item `total`, `limit` and `offset`. `config_json` is `{}`; raw source config is not returned. Each item contains the true `resolved_count`, at most three `resolved_cidrs` previews and `resolved_truncated`.
+
+Optional `q` searches value/name and kind. `filters` is JSON for at most ten filters: `{field:'value'|'kind',operator,values:string[]}`. Operators match the frontend's `is`, `is_not`, `is_any_of`, `is_not_any_of`, `contains`, `not_contains`, `starts_with`, `ends_with`, `empty` and `not_empty`. Filters combine with AND, values with OR. Filtering occurs over the entire list before pagination; nested-list value text includes its child name and ID. The deterministic SQLite `evofw_lower` function preserves JavaScript Unicode case folding for names.
+
+Manual source items are projected through SQLite JSON1 and external CIDRs through `ip_list_entries`; full rows/config/resolution arrays are not materialized in JavaScript before slicing. `GET /lists?view=summary` also excludes source config from the metadata catalog query. Defaults for both endpoints preserve legacy behavior.
+
+Observed Windows/in-memory endpoint test: 100000 unique IPv4 inputs returned 120 response bytes in approximately 1363 ms. A 200-item page from that list returned 31048 bytes; an exact filter for the 100000th item returned 524 bytes. These are local samples, not production or two-CPU capacity claims. Tests also cover full duplicate no-op without generation bumps, invalid mixed input preserving count/hash/revision, default legacy detail shape, bad paging/filter parameters, external-prefix pagination, bounded nested-list resolution previews and Unicode child-name filtering.