Extract JavaScript object literal method entities

[Iron-Ham]

Summary

• Extract JS/TS object-literal shorthand methods and function-valued properties under variable/field initializer entities
• Preserve nested diff granularity for object-literal methods while avoiding redundant variable container changes
• Tighten parent suppression to remove exact child content ranges so same-line parent/sibling changes remain visible

Fixes #266

Test plan

• cargo test -p sem-core
• cargo test -p sem-cli
• Built target/debug/sem and validated sem entities / sem diff against disposable git repos for shorthand methods, arrow/function-valued object properties, ignored empty/computed keys, and inline parent/sibling changes

Review

• Independent code_reviewer subagent reviewed the patch; addressed same-line suppression and missing pair-diff coverage findings
• claude -p reviewed the patch; addressed duplicate fallback and empty/dynamic object key hardening findings

[inspect-review]

inspect review

Triage: 19 entities analyzed | 0 critical, 0 high, 9 medium, 10 low
Verdict: standard_review

Findings (5)

1. [low] In strip_children_content, the function attempts to find child content within a search range but uses child.content which may contain leading/trailing whitespace or formatting differences from the actual source text. If the exact string match fails, it falls back to excluding the entire line range, which could exclude more content than intended. This is a logic error in the content stripping algorithm that could lead to incorrect diff suppression.
2. [low] In js_ts_object_initializer_children, the function filters for method_definition OR pairs with function values, but then returns ALL matching children with suppression_context set to "object". Later in extract_js_ts_object_function_pair, it only processes nodes when suppression_context == Some("object") AND the node is a pair. This means method_definition nodes will be added to the worklist with "object" suppression but won't be processed correctly, potentially causing them to be skipped or mishandled.
3. [low] In find_name_byte_range, the new code for handling pair nodes returns the byte range of the key, but this doesn't account for the fact that js_ts_object_key_name filters out empty keys, computed keys (starting with '['), and template strings with interpolation. If a pair has such a key, find_name_byte_range will return a byte range but extract_js_ts_object_function_pair will return None for the name, causing an inconsistency where an entity might be created with an invalid name or the wrong byte range.
4. [low] In extract_js_ts_object_function_pair, the function returns a tuple with the function value node, but the caller in visit_node pushes this value onto the worklist with Some(value.kind().to_string()) as suppression context. However, the value is the function node (arrow_function, function_expression, etc.), not "object". This means nested entities inside these functions won't have the correct suppression context.
5. [low] In js_ts_object_key_name, the function filters out keys that contains("${") to exclude template strings with interpolation. However, it only checks after trimming quotes from template_string nodes. A template string like `key${x}` would have its backticks trimmed first, leaving key${x}, which would then be filtered. But a regular string "key${x}" (literal text, not interpolation) would also be incorrectly filtered out.

---

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

[inspect-review]

inspect review

Triage: 19 entities analyzed | 0 critical, 0 high, 9 medium, 10 low
Verdict: standard_review

Findings (4)

1. [low] In strip_children_content, the function attempts to find child content within a search range but doesn't handle the case where child.content might span multiple lines or contain different whitespace than the parent content. The substring search content[search_start..search_end].find(&child.content) will fail if the child content has been normalized differently (e.g., different line endings, whitespace), causing the exclusion logic to silently fail and include child content that should be stripped.
2. [low] In js_ts_object_key_name, the function filters out template strings containing ${ but uses a simple contains check after trimming backticks. This means a key like "key${x}" (which is a regular string, not a template string) would pass through, but the test expects it to be extracted. However, if the tree-sitter parser marks it as a template_string node type, it would be incorrectly filtered out despite being a valid static key.
3. [low] In js_ts_object_initializer_children, the function sets suppression_context to Some("object".to_string()) for pairs with function values, but in extract_js_ts_object_function_pair, it checks suppression_context != Some("object") and returns None if it doesn't match. This means the function will only extract pairs when the suppression_context is exactly "object", but the worklist entry is created with this context. However, if a pair is visited through a different path without this context, it won't be extracted as a method entity.
4. [low] In push_js_ts_initializer_children, the function reverses the order of initializer children before pushing them onto the worklist with .rev(). However, js_ts_initializer_children can now return multiple children from js_ts_object_initializer_children, which are already collected in source order. Reversing them will cause object properties to be visited in reverse order, which may break assumptions about processing order.

---

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

[Iron-Ham]

Superseded by #309.