resolveChaTargets/resolve_cha_dispatch only walked implementors
(subclasses) starting from the receiver's declared type, never checking
whether that type itself is instantiated. When a class is instantiated
directly AND an unrelated file also declares a local subclass overriding
the same method (e.g. a test double), the base class's own method was
dropped from the resolved edge set while the unrelated subclass's
override leaked in instead (#2348).

Both engines now also resolve the receiver's own type via
resolveMethodViaAncestors/resolve_method_via_ancestors, gated on strict
new-expression evidence only (a new newExpressionTypes/
cha_new_expression_types set) rather than the merged instantiatedTypes/
cha_instantiated_types set (which also credits a bare high-confidence
type annotation as "instantiated"). The merged set is too broad for this
particular check: it would resurrect a distant interface's own bodyless
method whenever some unrelated concrete subclass overrides the same
method name, which regressed two existing native unit tests
(cha_typed_dispatch_fallback_resolves_distant_interface_implementation
and ..._respects_rta_filter) until this stricter gate was added.

Adds a dual-engine regression test
(issue-2348-cha-base-type-own-method.test.ts) reproducing the shape
with a synthetic base class + two unrelated local override subclasses,
verified to fail on both engines with the fix disabled and pass with it
enabled.

docs check acknowledged

Impact: 6 functions changed, 0 affected

Greptile review on PR #2494: newExpressionTypes/cha_new_expression_types
(added for #2348's receiver-own-type check) was a bare, project-wide
set with no file scoping, unlike implementorsByFile/cha_implementors_by_file
which this codebase already splits carefully for the same reason
(#2237). Two unrelated files can each declare their own unrelated class
with the same bare name; if only one is ever instantiated, the bare set
couldn't tell them apart, and resolveMethodViaAncestors/
resolve_method_via_ancestors' own bare/global fallback could then
resolve to the OTHER file's method.

Both engines now also track, per file: which type names it locally
declares (declaredTypeNamesByFile/cha_declared_type_names_by_file,
mirroring the same local-declaration anchor recordImplements/
recordExtends already use for implementorsByFile) and which type names
its own new-expression evidence names
(newExpressionTypesByFile/cha_new_expression_types_by_file). The
root-type check now prefers the file-scoped pair whenever the caller's
file locally declares the receiver type - trusting a scoped miss as
authoritative - and only falls back to the bare set when the caller's
file has no local declaration to anchor against (the same accepted
limitation implementorsByFile already has in that case).

Adds a dual-engine regression test proving the disambiguation (three
TS unit tests in cha.test.ts covering the collision, the same-file
positive case, and the no-anchor fallback; one Rust integration-style
unit test through build_call_edges), plus re-verifies the #2348
regression test and the real-world in-memory-repository.test.ts repro
are unaffected on both engines.

docs check acknowledged

Impact: 7 functions changed, 0 affected