fix(downloader): accept a 200 whose body is exactly the requested byte-range slice

RFC 9110 permits a server to ignore Range and answer 200 with the whole
resource. When the item's slice starts at byte 0 and spans exactly the
response body, that 200 is byte-identical to the 206, so keep it instead of
burning all five attempts and failing the track. Every other 200 (nonzero
start, span mismatch, open-ended, encoded) still fails the attempt to
protect the merge.

tests/downloaders/test_download_hardening.py

@@ -115,6 +115,17 @@ def test_range_item_ignored_by_server_fails_not_corrupts(server, tmp_path, monke
     assert not list(tmp_path.glob("seg_*.bin"))
 
 
+def test_range_item_spanning_whole_resource_accepts_200(server, tmp_path):
+    # RFC 9110 lets a server ignore Range and answer 200 with the whole resource; when
+    # the slice spans that whole resource the body is byte-identical to the 206, so it
+    # must be kept instead of burning five attempts and failing the track
+    server.honor_range = False
+    urls = [{"url": _url(server), "headers": {"Range": f"bytes=0-{len(PARENT) - 1}"}}]
+    files = _run(server, tmp_path, urls, max_workers=1)
+    assert files[0].read_bytes() == PARENT
+    assert len(server.requests) == 1
+
+
 def test_range_item_retry_rewrites_slice(server, tmp_path, monkeypatch):
     server.truncate_first = True
     monkeypatch.setattr(dl, "RETRY_WAIT", 0.01)