Find definitions by symbol, and decide against a second index

[Seungpyo1007]

Step 1 of the 0.4.0 plan, and the measurement that closes step 2.

What was broken

Ctrl+T returned nothing in a TypeScript project. It asked lspClient only, but TS/JS is served by Monaco's built-in worker, not an LSP session — this repository is exactly that case, so workspace symbol search has never worked here.

What it does now

src/editor/symbolIndex.ts merges both sources: the TS worker and any live LSP sessions. Ctrl+T and a new find_symbol agent tool share it.

Monaco's worker proxy does not expose getNavigateToItems — it answers Missing requestHandler or method. It does expose getNavigationTree, so workspace symbols are assembled from per-file trees. Flattening lives in src/engine/navTree.ts as pure functions with 18 tests.

The tool distinguishes no index from no match. Without that, "no such symbol" silently swallows "this language has no index at all", and the model concludes the thing does not exist.

Two kinds of noise are filtered out of the TS tree, both found by measuring rather than reading:

• import aliases — asking where applyProposal is defined returned the import line in a test file.
• describe("name", …) blocks — TS names those nodes after the string, so a test suite outranked the definition. These are pushed to the back rather than dropped, since sometimes the test is what you want.

Exact name matches are ranked first.

Measurement (this repository, 207 models)

Query	symbols	ms	grep	ms	first symbol result
applyProposal	5	200	27	36	engine/editApply.ts:41
flattenNavTree	2	171	25	36	engine/navTree.ts:38
writeAtomic	1	283	4	43	electron/checkpoints.cjs:66
notifyActiveEditor	1	150	3	31	ext/extHost.ts:90
planFileOps	6	155	33	29	ext/fileOps.ts:55
makeTouchSet	4	172	13	26	electron/touchSet.cjs:39

grep returns 5.5× more (105 vs 19). Symbols are 4–6× slower in absolute terms, but 150–280 ms is nothing inside an agent round. All six first results are the real definition.

What the measurement decided

Step 2 of the plan — building our own index — is dropped. The precision problem is already solved, TS/JS is covered by the worker and everything else by LSP, and a second table of the same facts would only add a staleness problem to maintain. The remaining gap is languages with neither, and that is a question of attaching a language server, not of building an index — and it pays better, since definitions, references and diagnostics all arrive together.

That also removes the update-strategy work the plan spent a section on: if we hold no table, nothing goes stale.

1089 unit tests passing. npm run typecheck clean. Verified in the real app on a fresh TypeScript project: 5/5, including that a comment mentioning the name and the call site are not returned.