README states what refused reports, one sender and nginx's 413 do (closes #145, closes #146, closes #147)

The README said the page keeps refused samples and sends them later.
They live only in the 100-round history, so at the 1-second interval
one refused or failed report loses the oldest 20 seconds of each host's
samples, and a pause longer than the history loses everything since the
last delivered report. Report limits now says one address at the
defaults can fill the 1 GiB cap in about 17 minutes with reports made to
compress badly, and which settings bound it. In the image, nginx's
default client_max_body_size of 1 MiB answers an over-limit body with
413 and an HTML page before the backend sees it; the backend's own 413
sentences now say they apply to it run on its own.

Model: opus-5-5

README.md

@@ -156,23 +156,21 @@ the next report. Delivery failure is quiet — one debug-log line per outage,
 never blocking probing. The report-building step is a pure function of host
 state.
 
-A sample in the history that no report has delivered is sent only as long as the
+A sample not yet delivered is kept only as long as the history holds it, so
-history holds it, so after a refused or failed report the next report carries
+after a refused or failed report the next report carries the samples the history
-the samples the history still has. Samples an interval change cleared from the
+still has. The history keeps each host's last 100 rounds: 100 seconds at the
-history are kept apart, the last 100 per host, until they are delivered. The
+1-second interval, 200 seconds at 2 seconds, 5 minutes at the default of 3
-history keeps each host's last 100 rounds: 100 seconds at the 1-second interval,
+seconds and 100 minutes at 60 seconds. At 1 second, one refused or failed report
-200 seconds at 2 seconds, 5 minutes at the default of 3 seconds and 100 minutes
+loses the oldest 20 seconds of each host's samples, as the next delivered report
-at 60 seconds. At 1 second, one refused or failed report loses the oldest 20
+comes 2 minutes after the last. At 2 seconds and longer one loses nothing;
-seconds of each host's samples, as the next delivered report comes 2 minutes
+samples are lost from the third refused report in a row at 2 seconds, from the
-after the last. At 2 seconds and longer one loses nothing; samples are lost from
+fifth at 3 seconds, and later still at the longer intervals.
-the third refused report in a row at 2 seconds, from the fifth at 3 seconds, and
-later still at the longer intervals.
 
 No report is sent while the page is paused, but each paused round still adds an
 entry to the history, so each report due during a pause counts as a refused one.
-A pause longer than the history spans loses the samples in the history recorded
+A pause longer than the history spans loses every sample recorded between the
-between the last delivered report and the pause: up to a minute's worth for each
+last delivered report and the pause: a minute's worth for each host if the
-host if the report before the pause was delivered.
+report before the pause was delivered.
 
 ### Backend
 
@@ -259,11 +257,11 @@ Files are created with `O_EXCL` to prevent overwrites.
 The reports of a failed write stay in memory, and the next flush, within a
 minute, tries again to write them. From the failed write until a write succeeds,
 `POST /api/v1/reports` refuses every report with 500 and keeps nothing of it.
-The page sends the refused samples again in its next report, as long as it still
+The page sends the refused samples again in its next report, as long as its
-holds them: at the 1-second interval one refused report already loses some of
+history still holds them: at the 1-second interval one refused report already
-those in the history (see [Reporting](#reporting)). Reports already answered 200
+loses some (see [Reporting](#reporting)). Reports already answered 200 are lost
-are lost only if the server stops before a write succeeds; the final flush at
+only if the server stops before a write succeeds; the final flush at stop tries
-stop tries them too, and if it fails, the process exits non-zero.
+them too, and if it fails, the process exits non-zero.
 
 #### Report limits
 

TODO.md

@@ -26,14 +26,12 @@ Run `make frontend-viewport-test` in CI as its own step; it is not part of
   how fast one address can replace the stored reports
   ([#146](https://git.eeqj.de/sneak/netwatch/issues/146)), and that in the image
   nginx answers a body over 1 MiB itself
-  ([#147](https://git.eeqj.de/sneak/netwatch/issues/147)). A sample in the
+  ([#147](https://git.eeqj.de/sneak/netwatch/issues/147)). A sample not yet
-  history that no report has delivered is sent only as long as the history holds
+  delivered is kept only as long as the history holds it: at the 1-second
-  it: at the 1-second interval one refused or failed report loses the oldest 20
+  interval one refused or failed report loses the oldest 20 seconds of each
-  seconds of each host's samples, and a pause longer than the history loses
+  host's samples, and a pause longer than the history loses every sample since
-  every sample between the last delivered report and the pause. Samples an
+  the last delivered report. At the defaults, one address sending 1 MiB reports
-  interval change cleared are kept apart, the last 100 per host, until they are
+  made up to compress badly can fill the 1 GiB cap in about 17 minutes. nginx's
-  delivered. At the defaults, one address sending 1 MiB reports made up to
-  compress badly can fill the 1 GiB cap in about 17 minutes. nginx's
   `client_max_body_size` is also 1 MiB by default, so in the image it answers a
   larger body with 413 and its own HTML page, and the backend never sees or
   records it; the backend's own 413 sentences now say they apply to it run on