fix(typescript): get_method class-only — module-level functions unreachable (local + Neo4j) #247

PROBLEM

The TypeScript backends' get_method is class-scope only, so module-level functions — the dominant callable kind in most TS code — are unreachable through it, and everything delegating to it inherits the blindness. The local backend's caller/callee path partially dodges this via _resolve_signature's bare-signature form, but the (class, member) form silently composes a guessed signature for unknown members instead of resolving module functions properly.

AFFECTED CODE (audit classes A4/A5)

• cldk/analysis/typescript/codeanalyzer/codeanalyzer.py:474 — get_method reads _methods_by_class only; module functions live in _functions, unreachable
• cldk/analysis/typescript/codeanalyzer/codeanalyzer.py:477 — get_method_parameters inherits it (false-empty [])
• cldk/analysis/typescript/neo4j/neo4j_backend.py:619 — Cypher matches [:HAS_METHOD] only; module-level functions hang off [:DECLARES] from Module/Namespace (see get_all_functions: DECLARES query in the same file)

FIX CONTRACT

1. get_method(scope, name): when scope is not a class (or class lookup misses), resolve module-level functions — local backend via _functions (exact signature, then short-name within the scope), Neo4j via a DECLARES fallback query mirroring get_all_functions.
2. get_method_parameters works for module functions on both backends.
3. Backend parity asserted in tests (local vs Neo4j same answers on the fixture).
4. No public signature changes; _resolve_signature's composed-guess fallback behavior is untouched here (its miss-discrimination is the 2.0.0 batch issue).

DEFINITION OF DONE

• Failing tests first: get_method + get_method_parameters for a module-level function on both backends, on a fixture where that function participates in a call edge.
• Existing tests green; no facade signature changes.
• Branch fix/issue-NNN; one PR closes this.

Found in the 2026-07-09 lookup audit (see #238 discussion; F1 oracle note on #239).