fix: prevent built-in Map calls from resolving to project methods (#1566)

[colbymchenry]

Fixes #1566.

Calls such as values.get() on a local Map and holder.values.get() previously linked to unrelated project methods named get, set, or has. These calls now stay unresolved, while a local new LRUCache() still resolves to that class's methods.

• Stop receiver-name guessing when the inferred JS/TS type is a known built-in and has no matching project method; share the existing built-in names between resolver paths, including WeakMap and WeakSet.
• Drop untyped identifier-rooted nested calls in both wasm and native extraction, while retaining calls inside their arguments and the existing window-namespace behavior.
• Add regression coverage for TS, TSX, JS, JSX, other built-in types, project-class receivers, built-in name shadowing, and kernel/wasm parity.

Verification on Linux x86_64, Node 22.19.0:

• Rebuilt and reproduced both failures on main at 72c1ff13: local Map produced three false edges at confidence 0.7; nested Map produced one at 0.9, in both engines.
• npx tsc, npm run copy-assets, and npm run build:kernel passed.
• Fresh CLI re-index plus SQLite checks in both engines: zero LRUCache callees from either Map function; all three project-class method calls retained at confidence 0.9; removing LRUCache also leaves zero false edges.
• Native: 920 tests passed across nine related suites, including kernel parity/scaffold. Wasm (CODEGRAPH_KERNEL=0): 889 tests passed across seven related suites.

Re-index after upgrading. Nested property types are not inferred by this change. PR #1691 was evaluated and not used: its this.<field>.method() work remains separately tracked by #1496/#1691.