Object literal computed method keys extract as `obj.['foo']` instead of `obj.foo`

[carlos-alm]

Bug

In `src/extractors/javascript.ts`, `extractObjectLiteralFunctions`'s `pair` branch (around line 1272-1273) only strips quotes for plain `string`-typed keys:

```ts
const keyName =
keyNode.type === 'string' ? keyNode.text.replace(/^['"]|['"]$/g, '') : keyNode.text;
```

For a computed string-literal key like `{ ['foo']: () => {} }`, `keyNode.type` is `computed_property_name`, not `string`, so this falls through to `keyNode.text`, producing the literal bracket/quote text. The emitted definition name becomes `obj.['foo']` instead of `obj.foo`, so `obj.foo()` call sites can never resolve to it.

Reproduced identically on both engines (not a parity gap — both are wrong the same way):

```js
const obj = {
['foo']: () => { return 1; },
bar: () => { return 2; },
};
obj.foo();
obj.bar();
```

`codegraph where --file sample.js -T --json` (both `--engine native` and `--engine wasm`) reports:
```json
{ "name": "obj.['foo']", "kind": "function", "line": 2 }
```
instead of `obj.foo`.

Fix direction

The adjacent `method_definition` branch in the same function already has a helper, `resolveMethodDefinitionName` (src/extractors/javascript.ts, extracted in the Titan phase 10 decomposition), that correctly unwraps `computed_property_name` -> inner `string`/`string_fragment` -> stripped text, returning `''` for unresolvable computed keys (e.g. `[Symbol.iterator]`). The `pair` branch's `keyName` computation should use the same unwrapping logic (skip the pair if the computed key isn't a resolvable string, mirroring the existing `method_definition` branch's `continue` behavior) instead of falling back to raw text. The mirrored Rust extractor (`crates/codegraph-core/src/extractors/`) should be checked for the same gap.

Found while auditing forge phase 10 (javascript.ts decomposition) during a Titan grind pass — out of scope for that phase's helper-adoption work, filed separately per project convention.

[carlos-alm]

Found a second, related site while adopting `resolveMethodDefinitionName` in a Titan grind pass: `handleObjectLiteralTypeMap`'s `method_definition` branch (src/extractors/javascript.ts, around what is now line ~2461) seeds the typeMap using `nameNode.text` directly with no computed-key handling at all:

```ts
} else if (child.type === 'method_definition') {
const nameNode = child.childForFieldName('name');
if (!nameNode) continue;
setTypeMapEntry(typeMap, `${lhsName}.${nameNode.text}`, `${lhsName}.${nameNode.text}`, 0.85);
}
```

For `const obj = { 'baz' {} }`, this seeds `obj.['baz']` instead of `obj.baz`. Meanwhile `extractObjectLiteralFunctions`'s `method_definition` branch (same file, already correctly using `resolveMethodDefinitionName` as of this grind pass) emits the definition under the correctly-unwrapped name `obj.baz`. So the typeMap seed and the definition it's supposed to point at disagree for computed method-shorthand keys, breaking `this.method()`-style resolution in that case.

Not fixing inline (out of scope for the current grind pass, which only touched the exact-duplicate `resolveMethodDefinitionName` pattern) — flagging so it's covered by the same fix pass as the `pair`-branch bug above, since both stem from inconsistent computed-key handling across `extractObjectLiteralFunctions`'s two branches and this typeMap seeder.