fix(parser): accept FN records with a negative line number

[Eljees]

Fixes the parsing half of #1514.

FN:-1,<name> is emitted for synthetic functions that have no source line — the reporter hit it with JaCoCo output for Scala's .curried/.tupled. The FN branch peeks at the first byte and rejects anything that is not a digit (src/parser.rs:289), so with the default (strict) mode manage_parsing_error! returns Err and the whole coverage file is dropped, not just the one record.

Function.start is a u32, so a negative line cannot be represented. The patch accepts an optional leading -, treats such a function as synthetic and records it at line 0, which keeps the function name and its FNDA counter working. A missing line number (FN:,name) stays an error — there is a test for that.

before / after

$ cargo test --lib FN_record    # master + new tests only
test test_lcov_parser_FN_record_without_line_number ... ok        # control
test test_lcov_parser_FN_record_with_negative_line_number ... FAILED
  ... called `Result::unwrap()` on an `Err` value: InvalidRecord("FN at line 3")

$ cargo test --lib              # master + new tests + fix
test result: FAILED. 135 passed; 4 failed        # same 4 llvm_tools failures as on master

The deadlock half of #1514 is not addressed here. The reporter also describes the main thread hanging in futex_wait when many worker threads panic. That is a change to the threading model in src/main.rs, and the trigger is the panics themselves — several of which are removed by #1515. Worth tracking separately.

Relationship to #1515. Both branches touch src/parser.rs, but they are independent and each is based on master, so they can be reviewed in either order. If #1515 lands first this one needs a trivial rebase — say the word and I will push it.

AI-assisted: I used Claude to help locate the strict-mode rejection and to draft the patch and the tests. I reviewed every line, ran the new test against unpatched master first to confirm it fails without the fix, and ran cargo fmt --check and cargo clippy -- -D warnings per the repo's pre-commit config; the analysis and the runs are mine.

[Eljees]

Same note as on #1515 about the red Lint job: it is pre-existing and not caused by this PR.

The five clippy errors are in src/producer.rs, src/path_rewriting.rs and src/cobertura.rs; this branch only touches src/parser.rs. Running the pre-commit clippy hook against pristine master and against master plus this patch gives exit 0 in both cases on the toolchain I had available, so the CI failure comes from a newer clippy rather than from the change. All ten test jobs here are green.

I listed the exact lints and offered a separate cleanup PR over on #1515, to keep the discussion in one place.