[TypeScript] func_start misses arrow/method-shorthand definitions not at line start (comma-sibling properties, nested one-line call arguments) #2277

Same sweep as #2276 (typescript tri-comparison ledger backlog): the remaining 2 of 3 real function-recall gaps found by a full-corpus func_start diff against tree-sitter (tri_comparison_gatherer.gather_language("typescript"), language-crucible/data/typescript) share a different root cause from #2276 — GitGalaxy's TypeScript object-literal-property / method-shorthand func_start branches require the property/method name to be at (or effectively at) the start of a line, so a real function value that isn't misses extraction entirely.

Example 1 — comma-preceded sibling property on the same line, playwright/frames.ts:1570:

next();
return { result, abort: () => aborted = true };

abort is a real arrow function (confirmed via tree-sitter's parse: name=abort, line=1570, 0 args) assigned as an object-literal property value, but it's preceded by result, on the same line rather than sitting at true line start.

Example 2 — method shorthand nested inside a one-line call argument, vscode/extHost.api.impl.ts:927:

return extHostProgress.withProgress(extension, { location: extHostTypes.ProgressLocation.SourceControl }, (progress, token) => task({ report(n: number) { /*noop*/ } }));

report(n: number) { /*noop*/ } is a real method-shorthand function (tree-sitter: name=report, line=927, 1 arg) nested three levels deep inside a single-line expression, never at line start.

Root cause, confirmed via isolated regex testing against LANGUAGE_DEFINITIONS["typescript"]["rules"]["func_start"]:

>>> pat.finditer('return { result, abort: () => aborted = true };')
[]   # misses it
>>> pat.finditer('abort: () => aborted = true;')
['abort']   # matches fine on its own line
>>> pat.finditer('foo(bar, { report(n: number) { } });')
[]   # misses it
>>> pat.finditer('report(n: number) { }')
['report']   # matches fine at true line start

The object-literal colon-style branch and the modifier/bare-method-shorthand branches are all anchored with ^[ \t]* (true line start, whitespace only); the assignment-style (name = ... =>) branch instead uses a lookbehind (?<=[^<>(,\s]) that excludes a preceding comma+space. Both mechanisms independently block a real function value from being recognized whenever it isn't the first thing on its line.

Confirmed scope: exactly these 2 occurrences across the full 23-file typescript corpus (0 elsewhere) — small and precisely bounded, but real. ctags also misses both (confirmed via direct ctags -x --languages=TypeScript --kinds-TypeScript=* runs against both files, no tags near either line), so this isn't uniquely a GitGalaxy gap, but it's a real, source-verified false negative independent of what any other tool does.

Why not fixed inline: loosening the line-start anchor risks reopening false positives on other same-line/nested constructs this shield presumably exists to filter out (the shield's own history — see #1631, #1629 — shows this branch has already been tuned against real false-positive incidents). A safe fix needs a scoped design pass (e.g. tolerating a preceding ,[ \t]* specifically, or bounded nesting-depth tracking for the call-argument case) with its own false-positive sweep, not a one-line tweak in this pass.