function_data.args count is wrong for ~68% of correctly-found functions -- overcounts simple signatures, zeroes out multi-line ones

[squid-protocol]

What

Measuring GitGalaxy's own args-count accuracy against Python's ast module as ground truth
(same corpus/methodology as #1198 and docs/language_status/python.md §9): of the 2333 real
Python functions GitGalaxy's extraction correctly finds by name, only 757 (32.4%) have the
right parameter count recorded in function_data.args. This number is essentially unchanged
before and after #1193 (which fixed comment-stripping, not args-counting) -- it's a distinct,
separate bug.

Two clear, different failure shapes in the mismatches, not one uniform "off by a bit" error:

1. Simple single-line signatures overcounted, often by exactly 1:

gitgalaxy/cobol_refractor_controller.py::main               real=0 got=2
gitgalaxy/cobol_refractor_controller.py::_init_sql_schema   real=1 got=2
gitgalaxy/cobol_refractor_controller.py::close              real=1 got=2
gitgalaxy/cobol_to_java_controller.py::format_java_header   real=1 got=3

def main(): (zero real parameters) is recorded as 2 args. This looks like the args regex
capturing something inside the parameter list that isn't a real parameter (a default value
expression, a type-hint's own internal comma, or similar) and miscounting commas/tokens as
separate arguments.

2. Multi-line signatures zeroed out entirely:

gitgalaxy/core/detector.py::__init__            real=4  got=0
gitgalaxy/core/detector.py::splice               real=6  got=0
gitgalaxy/core/detector.py::_slice_by_indentation real=5  got=0
gitgalaxy/core/detector.py::_slice_by_braces      real=6  got=0

These are real, ordinary methods whose def line's parameter list spans multiple physical
lines (long parameter lists with type hints, e.g. detector.py's own coding_analysis). The
args extraction appears to simply fail to match anything across a line break, recording 0
instead of the real count -- a much more severe failure than the overcount case above, since it
silently reports "no parameters" for functions that clearly have several.

Impact

This means args-derived signals (encapsulation heuristics, complexity scoring inputs, anything
downstream keyed on parameter count) are unreliable for roughly two-thirds of this corpus's
functions. Function recall (finding that a function exists) is unaffected -- this is purely
about the accuracy of one specific field once a function is already found.

How this was found

Same pass as #1198: diffing a fresh full self-scan against ast.parse()'s real
FunctionDef.args parameter counts (posonlyargs + args + kwonlyargs + 1 each for */** ),
corpus-wide across this repo's 228 Python files, immediately after #1193 merged.

Suggested next step

Not yet root-caused. Two separate investigations given the two distinct failure shapes:

1. For the overcount case, isolate why def main(): (a real zero-arg signature) parses to 2 --
   check whether the args regex/parser is picking up trailing content after the closing paren,
   or miscounting an empty/whitespace-only parameter list.
2. For the multi-line zeroing, confirm whether the args capture is anchored to a single
   physical line (no re.M/re.S spanning) and, if so, whether it can be safely extended to
   match across a parenthesized multi-line signature the same way func_start already does
   (per its own docstring, func_start already steps over decorators and PEP 695 generics
   across multiple lines -- args extraction may need the same treatment).

Also worth checking whether this repro-confirmed pattern generalizes past Python -- the
args rule key exists for every language, and multi-line signatures are common in strongly
statically-typed languages (Java, C#, TypeScript, Rust) too.