load tests: raise the iteration cap to 1,000,000,000

Both layers: the server's _TEST_LOAD_MAX and the PWA's
TEST_ITERATIONS_MAX plus the two input max attributes.  The value stays
inside 2^53-1 (the JavaScript safe-integer range), so the counters and the
progress display survive the JSON/JS round trip exactly; the practical
ceiling is the run duration (50 ms/iteration ~1.6 years at the cap).

The server's range error names the new cap automatically.  The frontend
tests read the cap from index.html instead of stubbing a literal, and
clamp at it (above the cap, exactly at it, and the input max).

Docs: api.md, test-scripts.md, help EN/RU, the CHANGELOG (folded into the
unreleased 3.38.0) and the AGENTS notes.  sw cache simple-v479.
1061 Python + 1071 frontend.

docs/api.md

@@ -1006,7 +1006,7 @@ on every stop** as long as the card is in the reader; a card reset (session
 change) stops the suite, skips the remaining members and is flagged in the
 report.
 
-`iterations` (optional, 1-1,000,000, default 1) repeats the script or the
+`iterations` (optional, 1-1,000,000,000, default 1) repeats the script or the
 whole suite: successful iterations are discarded (only the counter and the
 timing are kept; the per-step log is not retained), the first iteration that
 ends in an **error** stops the loop and keeps that iteration's report, a

docs/test-scripts.md

@@ -241,6 +241,8 @@ a manual stop ends it after the current iteration, and a card session change
 between iterations is an error.  The SCP80 counter state is shared across
 iterations, so packets continue from what the previous iteration consumed.
 The iteration count is a run parameter - the stored script/suite is unchanged.
+The accepted range is **1 to 1,000,000,000** (the PWA clamps, the server
+answers 400 above it).
 
 ## A card that stops answering