Default request limits per minute, hour and day, sized for API use (closes #176)

The default request limits now suit programmatic use of an API, such
as an automation fleet on another host, and still catch abusive bots:

- per minute: 300, passed within seconds by a client firing as fast
  as it can;
- per hour: 30000;
- per day: 300000, passed by a crawler that keeps up 4 a second.

At the default minute limit no client reaches the hour limit: 300 a
minute is at most 18,000 an hour.

The byte limits and ban lengths are unchanged. SPEC.md, README.md and
docs/settings.md give the reasons; docs/gitea.md redoes the Actions
runner sums.

Judgement call: the docs/alerts.md ban example shows the minute limit.

Model: opus-5-5

docs/gitea.md

@@ -34,11 +34,12 @@ checked again when gitea or the Core Rule Set changes version.
   day. One older than version 0.4 (April 2026) asks for work every 2 seconds,
   43,200 requests a day. While it runs a job, it reports the job's log and state
   every second instead, two requests a second. So one runner busy all day sends
-  172,800 requests, under the request limits. Six such runners on one address,
-  each busy all day, pass the day limit of 1,000,000 within two days; five stay
-  under it. Their address is then banned, their running jobs fail, and each
-  repeat within a day makes the ban longer. Newer runners ask for work less
-  often. Put the runners' addresses in `SWWAF_RATE_LIMIT_EXEMPT_NETS`.
+  120 requests a minute and 172,800 a day, under the request limits. Two such
+  runners on one address, each busy all day, make 345,600 and pass the day limit
+  of 300,000. Three busy at once make 360 a minute and pass the minute limit
+  of 300. Their address is then banned, their running jobs fail, and each repeat
+  within a day makes the ban longer. Newer runners ask for work less often. Put
+  the runners' addresses in `SWWAF_RATE_LIMIT_EXEMPT_NETS`.
 
 ## What the Core Rule Set lets through