Name request log actions so they say what they mean (closes #229)

The request log's `action` values now say what they mean, as sneak named them: `request_header_too_large`, `client_is_rate_limited`, `blocked_by_block_rule` and `client_denied`, with no aliases. `banned` splits into `temporarily_banned` and `permanently_banned`, by whether the ban runs out. When a permanent ban also covers a client, that ban is the one reported.

Trips a reader: a request over a rate limit stays `client_is_rate_limited` even when the ban it makes is permanent.
Disclosure: the offence key `rule_blocked` is renamed in `clients.json` too, so an existing file holding it stops the start and must be removed. Its `version` stays 1.

Model: opus-5-5

SPEC.md

@@ -321,6 +321,13 @@ ban is dropped alike. A scanner whose ban was dropped that way is refused and
 banned again by its next probe. A ban whose cause is `admin` is never dropped
 and does not count toward `SWW_MAX_BANS`, so such bans can never fill the table.
 
+A request refused under a ban that runs out is logged with the action
+`temporarily_banned`. Under a permanent ban the action is `permanently_banned`.
+A request refused for a clear sign of attack or a CrowdSec decision takes the
+action for the ban it made. A request that makes a ban permanent is logged as
+`permanently_banned`. A request over a rate limit is logged as
+`client_is_rate_limited`, whichever ban it makes.
+
 ## Settings
 
 `docs/settings.md` lists every setting with its default and the values it takes,
@@ -580,9 +587,10 @@ lower case, except a country code, which is in capitals. `SWW_TAG_DENY` and
 
 Two settings act on tags:
 
-- `SWW_TAG_DENY` lists tags whose requests are refused with the action `denied`
-  (`tag_deny`). The check runs twice: just before the rate limits, and again
-  after the Core Rule Set, so that `exploitsignature` can refuse too.
+- `SWW_TAG_DENY` lists tags whose requests are refused with the action
+  `client_denied` (`tag_deny`). The check runs twice: just before the rate
+  limits, and again after the Core Rule Set, so that `exploitsignature` can
+  refuse too.
 - `SWW_TAG_LIMIT_PERCENT` lists tags with a percentage from 1 to 99. Their
   clients get that percentage of every request and byte limit. The lowest
   percentage among a client's tags applies. `exploitsignature` cannot be listed,
@@ -1338,9 +1346,9 @@ over either one:
   `Transfer-Encoding` do not count. `X-Request-ID` and `X-Forwarded-Proto` do.
 
 Real clients never reach these limits. The answer is `deny` with `431`, and the
-log line's action is `too_large`. The refusal makes no ban and is no offence.
-The rate limits count the request as usual, so a client that keeps sending such
-requests breaks a limit.
+log line's action is `request_header_too_large`. The refusal makes no ban and is
+no offence. The rate limits count the request as usual, so a client that keeps
+sending such requests breaks a limit.
 
 The limits apply on every path and in every `SWW_WAF_MODE`. A client in
 `SWW_ALLOW_NETS` skips them, as it skips the Core Rule Set. In `observe` mode