Extract TypeScript ambient function signatures

[Iron-Ham]

Fixes #265

Summary

• extract TypeScript/TSX function_signature nodes so ambient declare function declarations appear as function entities
• suppress overload signature entities when a same-scope implementation exists
• cache implementation names per TypeScript scope to avoid repeated sibling scans in large declaration files

Test plan

• cargo test -p sem-core
• cargo test -p sem-cli
• dummy git repos under /tmp/sem-issue-265-* validating sem entities and sem diff for ambient declarations, overload de-duplication, nested namespace overloads, mixed export overloads, and declaration-file signature changes

[inspect-review]

inspect review

Triage: 12 entities analyzed | 0 critical, 0 high, 4 medium, 8 low
Verdict: standard_review

Findings (3)

1. [low] In should_skip_ts_overload_signature, the function only checks if a function_signature has a matching function_declaration implementation, but it doesn't handle the case where the implementation itself is also a function_signature (ambient function without body). This means declare function ambientFn(x: number): number; will be incorrectly skipped if there's another function_signature with the same name in the same scope.
2. [low] The collect_ts_function_implementation_names function only iterates over direct named children of the scope, but it doesn't recursively search for function declarations. This means nested function implementations (e.g., inside blocks or other statements) won't be detected, causing their overload signatures to not be skipped when they should be.
3. [low] The collect_ts_function_implementation_names function only collects direct named children of the scope, but in the test test_typescript_nested_overload_signatures_do_not_duplicate_implementation, the overload signatures and implementation are inside a namespace body. The function uses scope.named_children(&mut cursor) which only gets immediate children, so it won't find function declarations nested inside namespace bodies, class bodies, or other block structures. This means overload signatures inside namespaces won't be properly deduplicated.

---

Reviewed by inspect | Entity-level triage found 0 high-risk changes

[inspect-review]

inspect review

Triage: 13 entities analyzed | 0 critical, 0 high, 4 medium, 9 low
Verdict: standard_review

Findings (2)

1. [low] In should_skip_ts_overload_signature, the function collects implementation names lazily per scope, but the worklist processes nodes in reverse order (LIFO via pop()). This means function_signature nodes may be processed BEFORE their corresponding function_declaration implementations, causing the implementation name lookup to miss and incorrectly skip ambient signatures that should be kept.
2. [low] In ts_function_declaration_name, the function only checks if declaration.kind() == "function_declaration" but doesn't handle the case where the declaration itself might be wrapped in other node types. The logic assumes child_by_field_name("declaration") always returns a function_declaration directly, but export_statement declarations can be other types, potentially causing silent failures.

---

Reviewed by inspect | Entity-level triage found 0 high-risk changes

[Iron-Ham]

Superseded by #309.