fix: reject stray lines between file sections instead of silently dropping them

[code-yeongyu]

Fixes #45.

Summary

• The bug: between file sections the parser skipped any line not starting with *** . An indented file header was therefore dropped along with its hunk lines, and the patch reported success. As the first section, the same header failed with a misleading "no hunks found".
• The fix: file headers are recognized after trimming, as in Codex (streaming_parser.rs process_line). Any other non-blank line between sections rejects the whole patch with '<line>' is not a valid hunk header, before anything is applied. Indented markers inside an update hunk stay context lines, as in Codex.

Verification

• bun run check (typecheck + biome)
• bun run test: 67/67
• New test/patch-headers.test.ts: 6 user-facing cases. The 5 that exercise the fix fail on main and pass here. The sixth (an indented marker inside a hunk stays context) passes on both and guards against over-trimming.
• Codex's portable conformance scenarios (codex-rs/apply-patch/tests/fixtures/scenarios, 26 cases) replayed against this branch: 017_whitespace_padded_hunk_header now passes. The remaining two failures (023/024, line endings) are a separate fix.

apply_patch impact

• No schema or grammar change
• Path safety unchanged
• CHANGELOG entry under [Unreleased]

[code-yeongyu]

Lead in-session review at 0598319: PASS. File headers are recognized after trimming (Codex behavior), and a non-header, non-blank line between file sections now reaches the header parser and is rejected before anything is applied, instead of being skipped together with the section it introduced (the silent dropped edit). Add-file body lines start with '+', so the trimmed *** break can't fire on content. Tests are user-view (whole patch rejected, nothing changes).

[code-yeongyu]

Lead re-review of b3efd4c (extractPatchedPaths): right direction, one P1 left.

The parser recognizes headers with String.prototype.trim(), which strips ALL JS whitespace (\u00A0, \uFEFF, \v, \f, \u2000-\u200A, \u3000, ...), but the extractor regex only allows [ \t] around the header. So \u00A0*** Update File: x is parsed and written but NOT extracted: that file skips the per-file approval, the same bypass in a narrower form; and a trailing \u00A0 makes the approved path differ from the written one.

Fix: make the extractor use exactly the parser's notion of whitespace, e.g. derive both from one helper (split lines, .trim() each, then match ^\*\*\* (?:(?:Add|Delete|Update) File|Move to): (.+)$ on the trimmed line), or use [^\S\r\n]* on both sides plus a final .trim() on the captured path. Add a test with a \u00A0-indented and a trailing-\u00A0 header asserting extractPatchedPaths lists exactly the paths the parser will write.

[code-yeongyu]

Lead re-review of 36388ed: PASS. Parser and extractPatchedPaths now share parseFileHeader (String.prototype.trim) and parseMoveTo (trimEnd), so the whitespace definition is one by construction; the extractor's extra trimStart on Move to only over-approximates (fail-safe for per-file approval). The trailing-space Move to mismatch is fixed too, and the \u00A0 test asserts extracted == written. Merge on green.