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.
Those in the 100-round history are sent only while it holds them: at
the 1-second interval one refused report loses the oldest 20 seconds of
each host's samples, and a pause longer than the history loses every
sample between the last delivered report and the pause. Samples an
interval change cleared are kept apart, the last 100 per host, until
delivered. Report limits now says one address at the defaults can fill
the 1 GiB cap in about 17 minutes. In the image, nginx answers a body
over 1 MiB itself, with 413 and an HTML page; the backend's own 413
sentences now apply to it run on its own.

Model: opus-5-5

README.md

@@ -156,21 +156,23 @@ 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 not yet delivered is kept only as long as the history holds it, so
-after a refused or failed report the next report carries the samples the history
-still has. The history keeps each host's last 100 rounds: 100 seconds at the
-1-second interval, 200 seconds at 2 seconds, 5 minutes at the default of 3
-seconds and 100 minutes at 60 seconds. At 1 second, one refused or failed report
-loses the oldest 20 seconds of each host's samples, as the next delivered report
-comes 2 minutes after the last. At 2 seconds and longer one loses nothing;
-samples are lost from the third refused report in a row at 2 seconds, from the
-fifth at 3 seconds, and later still at the longer intervals.
+A sample in the history that no report has delivered is sent only as long as the
+history holds it, so after a refused or failed report the next report carries
+the samples the history still has. Samples an interval change cleared from the
+history are kept apart, the last 100 per host, until they are delivered. The
+history keeps each host's last 100 rounds: 100 seconds at the 1-second interval,
+200 seconds at 2 seconds, 5 minutes at the default of 3 seconds and 100 minutes
+at 60 seconds. At 1 second, one refused or failed report loses the oldest 20
+seconds of each host's samples, as the next delivered report comes 2 minutes
+after the last. At 2 seconds and longer one loses nothing; samples are lost from
+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 every sample recorded between the
-last delivered report and the pause: a minute's worth for each host if the
-report before the pause was delivered.
+A pause longer than the history spans loses the samples in the history recorded
+between the last delivered report and the pause: up to a minute's worth for each
+host if the report before the pause was delivered.
 
 ### Backend
 
@@ -257,11 +259,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 its
-history still holds them: at the 1-second interval one refused report already
-loses some (see [Reporting](#reporting)). Reports already answered 200 are lost
-only if the server stops before a write succeeds; the final flush at stop tries
-them too, and if it fails, the process exits non-zero.
+The page sends the refused samples again in its next report, as long as it still
+holds them: at the 1-second interval one refused report already loses some of
+those in the history (see [Reporting](#reporting)). Reports already answered 200
+are lost only if the server stops before a write succeeds; the final flush at
+stop tries them too, and if it fails, the process exits non-zero.
 
 #### Report limits
 

TODO.md

@@ -26,12 +26,14 @@ 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 not yet
-  delivered is kept only as long as the history holds it: 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 every sample since
-  the last delivered report. 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
+  ([#147](https://git.eeqj.de/sneak/netwatch/issues/147)). A sample in the
+  history that no report has delivered is sent only as long as the history holds
+  it: 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
+  every sample between the last delivered report and the pause. Samples an
+  interval change cleared are kept apart, the last 100 per host, until they are
+  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