fix(fortran): map source_location back through cpp linemarkers (#2092)

[SinghAman21]

What

Capital-F Fortran files (.F .F90 .F95 .F03 .F08) are run through cpp,
which was invoked with -P. -P suppresses linemarkers, and since cpp blanks
directive lines, drops inactive #ifdef blocks, and collapses blank runs, the
line numbers tree-sitter sees no longer match the original file.

Result: every symbol got a wrong source_location — including files with no
preprocessor directives at all (blank-line collapse). A confidently wrong line
sends explain / affected / the MCP read surface to unrelated code.

How

• Drop -P so cpp keeps its # <n> "<file>" linemarkers.
• _cpp_preprocess now returns (source, line_map); _strip_linemarkers
  consumes the markers to build a preprocessed-line → original-line map and
  hands tree-sitter marker-free source (blanks kept, so rows stay in lockstep).
• add_node / add_edge translate each line through _orig_line.
• Unchanged: the -nostdinc -I /dev/null security flags, and the raw-bytes
  fallback for lowercase .f90 and when cpp is absent (line_map = None).

Verified on the issue's example: module solver → L9, compute_volume → L12,
zebrafunc (after 5 blank lines) → L6.

Files

• graphify/extractors/fortran.py — run cpp without -P, parse linemarkers,
  translate node/edge lines.
• tests/test_languages.py — 2 location tests (directive case + blank-line case).
• tests/test_cpp_preprocess.py — updated for the new (bytes, line_map)
  signature; keeps the argument-injection check and adds a -P guard.
• CHANGELOG.md — entry under 0.9.24 (unreleased).

Reference

• Issue Every symbol in a .F/.F90/.F95/.F03/.F08 file gets a wrong source_location — cpp -P renumbers lines with no way back #2092
• Root cause: graphify/extractors/fortran.py (cpp -P invocation).

Conclusion

Fortran symbols now report their true source line regardless of extension or
preprocessor directives. Full suite green (pre-existing unrelated
test_ollama_retry_cap.py failures aside).