SPEC: false statements fixed, repeats removed, dropped requirements restored

The bounds sentence, the blocklist URL sentence, the deny list sentence,
the limit action's scope and the observe mode sentence now say what the
code does. Each of the twenty-one requirements the fourth review found
twice is stated once, with a link from the other place. The request id
header, redirect_uri's case, change 4's reason and the live archive's
InRelease files are back. The biased thresholds are defined where they
are introduced. The docs files apply the fifth README review's findings
and stay identical to the README branch.

Model: fable-5-1

docs/state-files.md

@@ -15,8 +15,8 @@ those `smallwebwaf` made. Per entry:
 - `lifted`: when an admin lifted it, if one did;
 - `notes`: the notes below.
 
-To ban a netblock, add an entry with its `netblock`, `start` and `expires`.
-`reason`, `notes` and `cause` may be left out; the cause is then `admin`:
+An entry an admin adds needs `netblock`, `start` and `expires`; `reason`,
+`notes` and `cause` may be left out, and the cause is then `admin`:
 
 ```json
 {
@@ -32,20 +32,23 @@ To ban a netblock, add an entry with its `netblock`, `start` and `expires`.
 }
 ```
 
-To lift a ban, add `"lifted"` with the time you lift it, such as
-`"lifted": "2026-10-06T13:00:00Z"`. To keep a ban `smallwebwaf` made, set its
-`cause` to `admin`. To forget a ban, delete its entry.
-
-The notes:
+"Bans" in [`SPEC.md`](../SPEC.md) says how an edit lifts, keeps or forgets a
+ban. The notes:
 
 - `asn`, `as_name` and `country`: the client's, added when the lookup answers
   (empty when lookups are off);
-- what was broken: the rule id and target that matched, or the trap path, or the
-  limit, its window and the count reached;
-- the client's percentage of the limit, with the setting that gave it;
-- the reputation sources the client is on;
-- `request`: the request that caused the ban: time, method, host, path with its
-  query string, status and user agent, each text cut to 256 bytes;
+- for a broken limit, `kind` (`requests`, `bytes` or `refusals`), `limit`,
+  `window` and `count`: what the limit was on, the limit, its window and the
+  count reached;
+- `limit_percent` and `limit_percent_setting`: the client's percentage of that
+  limit and the setting that gave it, when a setting lowered it;
+- for a clear sign of attack, `rule_id` and `target`, or `trap_path`;
+- `reputation`: the sources the client was on, each with its `source` and, for
+  AbuseIPDB, its `score`;
+- `request`: the request that caused the ban, each text cut to 256 bytes:
+    - `time`, `method` and `host`;
+    - `path`, with its query string;
+    - `status` and `user_agent`;
 - `requests` and `refused`: the netblock's requests since it was first seen, and
   how many this ban has refused so far, kept up to date while the ban lasts;
 - `earlier_bans`: how many earlier bans the netblock had, by cause.
@@ -93,8 +96,9 @@ GeoJS answers, one per line:
   `SWWAF_MAX_TRACKED_CLIENTS`. Written every 15 minutes, that is under 2 GiB of
   disk writes a day.
 - `bans.json`: about 1.2 KiB per ban, at most about 2.5 KiB, so about 6 MiB at
-  the default `SWWAF_MAX_BANS`. With a full file, a hundred new bans a day come
-  to about 600 MiB of writes.
+  the default `SWWAF_MAX_BANS`. Written every 15 minutes, a full file comes to
+  about 600 MiB of writes a day, and a hundred new bans a day add about 600 MiB
+  more.
 - `lookups.json`: about 150 bytes per answer, under 1.5 GiB of writes a day when
   full.
 - `reputation.json` and `alerts.json`: usually a few MiB or less.