fix: correct Content-Range end byte in chunked upload (RFC 7233)

[chrisdebian]

Summary

• Fixes MapSyncer issue Update README.md #87 — Invalid "Content-Range" provided error when uploading large tracks (>64 MB, i.e. more than one chunk).
• The upload loop in upload_manager.py was sending bytes={offset}-{entity_size}/{entity_size} for every chunk. RFC 7233 requires the end value to be the last byte of the current chunk (0-indexed, inclusive), not the total file size. For multi-chunk uploads this meant every intermediate chunk carried an invalid range, causing the server to reject it.
• Adds two unit tests: single-chunk and multi-chunk Content-Range header construction.

Root cause

# Before (wrong — end is total size, not chunk end):
"content-range": f"bytes={offset}-{self.entity_size}/{self.entity_size}"

# After (correct — end is last byte of this chunk):
chunk_end = (offset + len(chunk) - 1) if chunk else self.entity_size
"content-range": f"bytes={offset}-{chunk_end}/{self.entity_size}"

Related issues

• Fixes the root cause reported in {"message":"Invalid "Content-Range" provided"} when uploading tracks MapSyncer#87
• None of uploaded sequences ever shown in the app MapSyncer#89 (sequences not appearing) may also improve if upload failures were silently dropping sequences

Test plan

• pytest tests/test_upload_manager.py — 2 new tests pass
• Full suite: pytest — 97 tests pass
• On-device: upload a sequence larger than 64 MB and confirm no Invalid Content-Range error

🤖 Generated with Claude Code

[chrisdebian]

Hi,

Just flagging that this is the root cause behind the MapSyncer upload failures reported in MapSyncer #87 and #89 — users hitting 'Invalid Content-Range' on any track over 64 MB. The fix and unit tests are ready whenever you have a moment to review.

Thanks, Chris