Residual function-extraction gap post-#1193: contiguous dead zone + near-total loss in embedded-foreign-code-heavy files

[squid-protocol]

What

Re-measuring GitGalaxy's own Python function-extraction recall against ast ground truth
(same methodology as docs/language_status/python.md §9, and the pass that originally found
#1182/#1183/#1184/#1193) after #1193 landed: real-pipeline recall jumped from #1193's own
measured ~60% to 98.1% (2333/2379 real functions found, corpus-wide across this repo's own
228 Python files). Class recall is 100%, and there are zero hallucinated/extra function
names anywhere in the corpus -- precision is effectively perfect.

The remaining ~2% gap (46 missing functions) is not scattered noise -- it's concentrated in
exactly 4 of 228 files, in two distinct shapes:

1. A small contiguous "dead zone" in gitgalaxy/core/detector.py itself -- 7 functions in
a row, _partition_segments through _apply_literal_shield (lines 931-1289), all missing while
every function immediately before and after this range is found correctly. None of these are
edge cases: they're ordinary single-line def signatures on a normal method inside a class, no
unusual indentation, no embedded-language content nearby. This is the same shape of bug #1184
fixed (a contiguous range of real functions silently lost), so it's plausibly a sibling trigger
of the same underlying "scope desync" bug class, not necessarily #1193 recurring.

2. Near-total extraction loss in two test files whose content is dominated by embedded
foreign-language code snippets:

• tests/extraction/languages/test_rust_strict.py: 1 of 18 real functions found
  (only test_rust_macro_invocation_boundary_regression, at line 136 -- neither the functions
  before nor after it are found).
• tests/extraction/languages/test_objectivec_strict.py: 5 of 11 found (6 missing).

Both files' coding_loc is a healthy fraction of total_loc (test_rust_strict.py: 276/449), so
this isn't "the whole file got swallowed as one big comment" -- the code IS being retained in
code_stream, but the function-boundary scanner isn't recognizing most of the individual defs
inside it. This smells like the same "language gravity" misdetection class #1183 fixed (a string
literal containing embedded-language-shaped syntax misleading _partition_segments/handshake
detection), given these files are full of literal Rust/Objective-C code snippets as Python string
data -- but not confirmed; could equally be a _slice_by_indentation boundary-tracking issue
specific to these files' structure.

Impact

Real, measurable, but small (46/2379 functions, 1.9%) -- worth fixing but not urgent. Filed
mainly so it isn't silently lost as noise now that #1193 closed the dominant gap.

How this was found

Diffing a fresh full self-scan (python tests/tools/self_scan.py, DB deleted first to force a
full rescan) against Python's ast module, corpus-wide across this repo's 228 Python files, as a
follow-up measurement immediately after #1193 merged. Same methodology as
docs/language_status/python.md §9.

Suggested next step

Not yet root-caused. Start by isolating whether _partition_segments/embedded-language
detection is firing anywhere inside test_rust_strict.py (matching #1183's diagnostic approach:
check for any embedded-language trigger match inside the file, even inside a string literal),
and separately, minimize detector.py's _partition_segments-through-_apply_literal_shield
range to the smallest reproducible input that still drops all 7 functions.