Computed string-literal keys not unwrapped in several typeMap/prototype extraction sites (both engines)

[carlos-alm]

Bug

While fixing #1764 (extractObjectLiteralFunctions's pair branch emitting obj.['foo'] instead of obj.foo for computed string-literal keys), the same "only unwrap plain string-typed keys, fall back to raw bracket/quote text for computed_property_name" pattern was found in several other object-key extraction sites across both engines. These are separate from the #1764 fix (which only covers extractObjectLiteralFunctions / extract_object_literal_functions + match_js_objlit_qualified_method_defs, the functions that determine Definition.name) — the sites below all feed typeMap seeding or other adjacent extraction paths, not Definition.name directly, so they don't affect codegraph where's reported name, but they do affect resolution correctness (dangling/garbled typeMap keys) for the affected call patterns.

None of these unwrap computed_property_name → inner string/string_fragment the way resolveMethodDefinitionName/resolve_method_def_name (and now the fixed pair branches) do.

TypeScript (src/extractors/javascript.ts)

• handleObjectLiteralTypeMap's pair branch — same string-only gap for typeMap seeding (used for this.x() resolution via object-literal aliasing).
• handleObjectLiteralTypeMap's method_definition branch — worse: doesn't call resolveMethodDefinitionName at all, uses raw nameNode.text unconditionally (would even mishandle a [Symbol.iterator]-style key, not just string literals).
• handleDefinePropertyTypeMap's defineProperties pair-iteration branch — same string-only gap for Object.defineProperties(obj, { ['foo']: descriptor }).
• seedProtoProperties's pair branch — same string-only gap (seeds pts keys from Object.create({ ['foo']: identifier })-style prototype object literals).
• collectObjectRestParams's pair branch — different shape: explicitly excludes all computed keys via keyN.type !== 'computed_property_name', including resolvable string literals (under-extraction rather than a garbage name, but same root cause — worth unwrapping resolvable ones instead of blanket-skipping).
• extractPrototypeObjectLiteral's method_definition branch — doesn't call resolveMethodDefinitionName, raw nameNode.text (also a cross-engine divergence: the Rust mirror extract_js_prototype_object_literal already calls resolve_method_def_name correctly here).
• extractPrototypeObjectLiteral's pair branch — same string-only gap.

Rust (crates/codegraph-core/src/extractors/javascript.rs)

• seed_objlit_type_map_entries (mirrors handleObjectLiteralTypeMap) — same string-only gap in its pair arm.
• seed_object_create_entries (mirrors seedProtoProperties's Object.create path) — same string-only gap in its pair arm.
• seed_descriptor_object (mirrors handleDefinePropertyTypeMap's defineProperties path) — same string-only gap.
• extract_js_prototype_object_literal's pair arm (mirrors extractPrototypeObjectLiteral) — same string-only gap. (Its method_definition arm is already correct — see the TS cross-engine divergence note above.)

Suggested fix

src/extractors/javascript.ts now has a shared resolveComputedKeyName(nameNode) helper (extracted from resolveMethodDefinitionName as part of #1764's fix) that unwraps a computed_property_name to its inner string-literal text, or '' if unresolvable. The Rust mirror has the equivalent resolve_computed_key_name / resolve_pair_key_name helpers. Each site above should route its key resolution through these shared helpers instead of duplicating the keyNode.type === 'string' ? ... : keyNode.text (or key_n.kind() == "string") ternary, and skip (not emit) entries whose computed key isn't a resolvable string literal.

Context

Found during the #1764 fix. Not fixed there to keep that PR scoped to the Definition.name bug specifically (extractObjectLiteralFunctions / extract_object_literal_functions + match_js_objlit_qualified_method_defs).