[mayuriphad]

Fixes #302

When a provider returned a 429 during an SRT refine pass, RateLimitError propagated out of refine_srt_file and nothing was written. Every cue already refined was lost, so a resume started again from the first cue. #252 fixed this for the TXT refiner and Plain Text Mode, but not for SRT.

This follows the TXT refiner's approach:

• refine_subtitle_translations now attaches the refined subtitles to RateLimitError.partial_result before re-raising, as a position-keyed dict. Subtitles not refined yet keep their draft text.
• refine_srt_file catches the error and writes that partial result with the same update_translated_subtitles / reconstruct_srt path as a normal save, then re-raises so auto-pause still triggers. The write is factored into _write_refined_srt.

Tests: added test_refine_srt_rate_limit_saves_refined_cues. A fake client refines the first block and then returns a 429. The test checks that the error still propagates and that the output has the first cue refined and the other two unchanged, under their own timestamps. It fails on main because no output file is written, and passes with this change. test_srt_refine_indexing.py and test_rate_limit_partial_refine.py pass: 15 passed.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[hydropix]

Thanks for working on this, Mayuri, and sorry it sat for a week. The fix landed in #313, which follows the same idea as yours (attach the refined cues to RateLimitError.partial_result and write them before re-raising). It also goes one step further on resume: the SRT refiner now receives the checkpoint and resume index, reads the finished cues back from the partial file and only sends the remaining ones to the model, so a resume no longer starts over from the first cue. Your branch also conflicts with main now, so I'm closing it in favor of #313. Thanks for the contribution.