test: round 4 — an assertion that could not fail, and a comment that did not add up

Two findings, both in the review's own work; nothing in the product code. That is
the shift that ends the loop: 22 → 13 → 6 → 2, and the last two are a test and a
comment rather than a defect.

The "an override that is fine is still honoured" leg of the bounds-fallback test
stored `spec.max` — which, for this key, IS the env default, because the spec's
max is derived from it. So the assertion was satisfied by the fallback it existed
to rule out: mutating `_coerce` to reject EVERY int override left all three legs
green. It stores `spec.max - 1` now and asserts the value differs from the
default, so the leg can actually fail.

And the shrink test's comment claimed `3 - 5 = -2` for an expression that computes
`chips.length - visible` = `2 - 3 = -1` — naming neither operand nor the result,
in a comment that was rewritten one round earlier precisely for miscounting.

backend/tests/test_body_limit.py

@@ -284,9 +284,14 @@ def test_a_stored_override_outside_the_bounds_falls_back_on_READ(db):
     db.commit()
     assert sysconfig.get_int(db, "download_upload_max_bytes") == default
 
-    row.value = str(spec.max)  # still in range — an override that is fine is still honoured
+    # An override that IS in range must still be honoured — otherwise a bounds predicate written
+    # backwards would make every override inert and the two assertions above could not tell.
+    # Deliberately not `spec.max`: that equals the env default for this key, so the assertion would
+    # be satisfied by the fallback it is meant to rule out.
+    row.value = str(spec.max - 1)
     db.commit()
-    assert sysconfig.get_int(db, "download_upload_max_bytes") == spec.max
+    assert spec.max - 1 != default
+    assert sysconfig.get_int(db, "download_upload_max_bytes") == spec.max - 1
 
 
 def test_the_cap_sits_inside_the_response_decorators_and_outside_the_setup_gate():