New defaults for the request and byte limits (closes #161)

A client is one IPv4 address or one IPv6 group, often several people
behind one NAT. The limits now sit about twice above what 40 people
busy with heavy web apps make together on one address: 6000 requests a
minute, 100,000 an hour and 1,000,000 a day; 4 GiB a minute, 20 GiB an
hour and 200 GiB a day. The largest response drops from 5 GiB to
1 GiB, so the minute byte limit still holds two of them. SPEC.md gives
the new reasoning; README.md and the reference documents give the new
figures.

Model: opus-5-5

docs/gitea.md

@@ -11,8 +11,10 @@ checked again when gitea or the Core Rule Set changes version.
 
 - SSH access to gitea does not pass through `smallwebwaf` and is not protected
   by it.
-- A clone is a response. It fits the defaults of 30 minutes and 5 GiB for all
-  but the largest repositories and slowest links.
+- A clone is a response. It fits the defaults of 30 minutes and 1 GiB unless the
+  repository is large or the link slow. A repository whose clone is larger than
+  1 GiB needs `SWWAF_RESPONSE_MAX_BYTES` raised, and the byte limits with it
+  ("Byte limits, per client" in `SPEC.md`).
 - A push is a request, and so is every other upload:
     - a git push;
     - an LFS object;
@@ -30,12 +32,13 @@ checked again when gitea or the Core Rule Set changes version.
   request limits do most of the work there.
 - An Actions runner that reaches gitea through `smallwebwaf` sends requests all
   day. One older than version 0.4 (April 2026) asks for work every 2 seconds,
-  43,200 requests a day, and reports a running job's log and state every second.
-  So it passes the day limit of 50,000 after about an hour and a quarter of
-  jobs. It is then banned, the job it is running fails, and each repeat within a
-  day makes the ban longer. Newer runners ask less often, but a busy one, or
-  several on one address, can still pass it. Put the runners' addresses in
-  `SWWAF_RATE_LIMIT_EXEMPT_NETS`.
+  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 after about 23 hours; 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`.
 
 ## What the Core Rule Set lets through