Design a Resumable Iterator with Checkpoint and Restore

Design a resumable iterator: an iterator that can serialize its current position into a compact, opaque checkpoint and later be reconstructed from that checkpoint so that iteration continues from exactly where it left off — even in a brand-new process.

You will build this in two stages, and you are expected to write the tests first, then implement against them. Your test suite must be detailed enough that a correct implementation passes immediately on the first run.

Stage 1 — List iterator

Implement ResumableListIterator over an in-memory sequence.

It must support:

• has_next() -> bool — whether another element remains.
• next() -> T — return the next element and advance; raise StopIteration (or your language's equivalent) if none remain.
• save_state() -> State — return a checkpoint capturing the current position. The checkpoint must be a value that can be stored and passed around (e.g. an integer, a string, or a small serializable object). It must not be a live reference to the iterator's internal mutable state.
• A constructor / factory that builds an iterator from (source, state) so that resuming from a saved checkpoint yields exactly the elements that had not yet been returned at the moment save_state() was called.

Resume semantics, precisely:

• If you call save_state() after returning the first k of n elements, then build a new iterator from the same source plus that checkpoint, the new iterator must return elements k, k+1, ..., n-1 (0-indexed) in order and then report no more.
• Saving at the very start (before any next()) resumes from the first element. Saving after the last element resumes into an empty iterator (has_next() is false).
• save_state() is a read-only operation: calling it must not advance the iterator or change what the original iterator yields next.

Stage 2 — File iterator (follow-up)

Implement ResumableFileIterator that yields the lines of a text file one at a time, with the same has_next / next / save_state / resume-from-state contract as Stage 1.

Additional requirements specific to files:

• The checkpoint must let a fresh iterator (in a new process, with the file reopened) resume at the next unread line without re-reading or re-emitting any line already returned.
• Do not require loading the whole file into memory; the iterator must stream so that it works on a file far larger than available RAM. Your checkpoint should therefore be small and must not embed the file's contents.
• State the assumptions your checkpoint relies on (for example, that the underlying file is not modified between save and resume), and design the checkpoint so that resuming lands on a well-defined line boundary rather than mid-line.

Required output / deliverables

1. A test suite covering at minimum: resume from the start, from the middle, from the end (empty resume), and a round trip where you iterate part-way, checkpoint, reconstruct, and assert the remaining sequence equals the expected tail. Include a test asserting save_state() does not mutate the original iterator.
2. The ResumableListIterator implementation passing those tests.
3. The ResumableFileIterator implementation passing line-based versions of the same tests, plus a test that resume continues at the correct line boundary on a multi-line file.

Constraints & Assumptions

• Elements/lines are returned in their original order; no skipping, no duplication across a save/resume boundary.
• A checkpoint produced by save_state() is opaque to callers and portable: it can be serialized (e.g. to JSON or a primitive) and used to reconstruct the iterator later, possibly in a different process.
• For the file iterator, assume the file is encoded in a single, known text encoding (e.g. UTF-8) and is not concurrently modified between checkpoint and resume.
• Aim for $O(1)$ additional memory per next() for the file iterator (streaming), and a checkpoint whose size is independent of how many elements have already been consumed.