Hub stage 6: blocking and cache actions on several servers

One endpoint, hub/servers/run (operate), runs a fixed set of actions on
the chosen servers in parallel with each server's admin token: add or
remove a domain in Blocked or Allowed, disable blocking for a time or
enable it, update block lists, replace the block list URLs, flush the
cache or delete a domain from it. Each server gets its own result and
the console offers Retry failed.

In "All servers", Blocking, Cache and Query Logs rows open this flow
instead of being disabled. The hub validates domains, minutes and the
server's list grammar (allow lists with !, switched-off lines with #)
and logs no URL list. Operators can now use the blocking switch.

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

hub/README.md

@@ -58,7 +58,7 @@ atomically with mode 0600. The running hub notices a change on the next request
 | `apps-admin` | read, apps.write |
 | `admin` | everything, including audit.read |
 
-`apps.write` is what the app writes below need; `operate` and the rest are still unused. Every response also carries
+`apps.write` is what the app writes below need; `operate` and `admin` are what the per-server and several-server changes need. Every response also carries
 `hubRole` (and `info.hubRole`).
 
 ## Login protection
@@ -86,6 +86,31 @@ Public: `status`, `user/login`. After signing in: `user/session/get`, `user/logo
 
 Everything else answers `403 The hub is read-only.` and is audited.
 
+## Changing several servers at once
+
+`POST hub/servers/run` (`write-all`, role with `operate`) runs one fixed action on the chosen servers, in parallel, each with
+that server's admin token. Parameters: `action`, `targets` (comma separated server ids) and the action's own `domain`,
+`minutes` or `urls` (lines in the grammar of the block lists, up to 300: `<url>`, `!<url>` for an allow list, `#...` for a switched-off list or a heading; http, https or file URLs; a line with a comma is refused). The answer is `{results: [{server, ok, message}]}`,
+one per server; a server with no admin token or one that does not answer fails on its own and the others still run. Empty
+targets or an unknown server are refused with `400`, and so is a bad parameter, before any server is called.
+
+| action | Technitium call | parameters sent |
+|---|---|---|
+| `blocked.add`, `blocked.delete` | `blocked/add`, `blocked/delete` | `domain` |
+| `allowed.add`, `allowed.delete` | `allowed/add`, `allowed/delete` | `domain` |
+| `blocking.disable` | `settings/temporaryDisableBlocking` | `minutes` (1 to 1440) |
+| `blocking.enable` | `settings/set` | `enableBlocking=true` only |
+| `blocking.updateLists` | `settings/forceUpdateBlockLists` | none |
+| `blocking.setListUrls` | `settings/set` | `blockListUrls` only (comma joined) |
+| `cache.flush` | `cache/flush` | none |
+| `cache.delete` | `cache/delete` | `domain` |
+
+The block list URLs are part of blocking, so `blocking.setListUrls` needs `operate` like the rest (the per-server
+`settings/set` of any other field still needs `admin`). `settings/set` with `enableBlocking` as its only field is `operate`
+too, so an operator can use the blocking switch on one server. The audit log gets one line per server with the action, the
+server, the domain or `minutes=N` or `urls=N` and the outcome, never the URL list. On the servers, the hub-admin needs
+Blocked and Allowed Modify and Delete, Cache Delete, and Settings Modify (list URLs, blocking switch).
+
 ## Managing one server
 
 The sections Zones, Cache, Blocking (Blocked and Allowed), DNS Client, Settings and DHCP are managed on ONE server at a