[YuriNachos]

Problem

SrtParse.parsePart can hang forever (infinite loop) while parsing SRT input whose trailing content is not a numeric cue index. Reproduces with any of:

• a stray non-numeric line after the last cue (e.g. a truncated download, a BOM/separator line, a tool signature);
• trailing whitespace-only lines;
• an SRT-shaped file that contains --> (so canParse accepts it) but never yields a numeric sequence line.

Once this happens the whole subtitle parser never returns.

Root cause

The sequence-number scan in SrtParse.parsePart has no end-of-input guard:

repeat {
    decimal = scanner.scanUpToCharacters(from: .newlines)
    _ = scanner.scanCharacters(from: .newlines)
} while decimal.flatMap(Int.init) == nil

When the scanner is parked on a non-numeric line at end of input, scanUpToCharacters(from: .newlines) returns nil (the current character is already a newline / EOF) and scanCharacters(from: .newlines) returns nil (nothing left to consume). Neither call advances the position, and decimal.flatMap(Int.init) stays nil, so the loop spins forever.

The sibling VTT parser already defends against this — VTTParse.parsePart terminates its timestamp-scan loop with && !scanner.isAtEnd; SRT was simply missing the same guard.

Fix

Add && !scanner.isAtEnd to the loop condition (one line). After the loop, scanner.scanUpToString("-->") returns nil at EOF, the existing if let startString, let endString = … check fails, parsePart returns nil, and the outer while !scanner.isAtEnd loop in parse(scanner:) exits cleanly.

Verification

• swift build for macOS: clean.
• swift test --filter SubtitleTest: passes (3 cases), including the new testSrtTrailingJunkDoesNotHang and the existing testSrt (still 9 cues, parts[8].end == 3601.14 — no regression).
• Without the guard the new test never returns (the loop hangs), which is exactly the bug.