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 <[email protected]>

hub/session.ts

@@ -35,9 +35,9 @@ and is always there. Administration (users, SSO, LDAP of each server) is not off
 What a role may change comes from its capabilities, per key. Settings never get `canDelete`
 (that is the backup and restore, which the hub does not forward), nor do the Logs and the
 Dashboard (deleting logs and stats stays in each server's own console). DNS Client needs
-`admin` to modify because its Import writes a zone. The Settings key also gates the
-temporary blocking switch in the console, which the hub itself would let an operator use:
-the console is the stricter of the two there.
+`admin` to modify because its Import writes a zone. The blocking switch and the block list update are blocking,
+so behind a hub the console asks for Blocked/Allowed Modify there (which an operator has), not for Settings Modify (which
+only an admin has). Saving the list URLs of one server stays a settings change.
 */
 const PERMISSION_KEYS = [
   'Dashboard', 'Zones', 'Cache', 'Allowed', 'Blocked', 'Apps', 'DnsClient', 'Settings', 'DhcpServer', 'Administration', 'Logs',