Classify the panel's code column with real token types

The panel guessed that any capitalised identifier was a type, so
`Profiler.Frames.Count` came out as three type-coloured names where the
editor shows a class and two members. The semantic overlay already fetches
per-file tokens, so feed the same data to the webview.

- codeSpans() returns the server's token spans per referenced line in the
  row's own trimmed coordinates; rows carry them and the webview colours from
  them, mapping token type names to its palette. Fields, properties, events
  and methods share the member colour, as they do in the stock themes.
- The regex tokenizer stays as the fallback for servers that serve no
  semantic tokens, and coloredReferences.semanticTokens now gates both views
  rather than just the editor.

Colours are still the approximated Dark+/Light+ palette — a webview is not
given the theme's token colours — so only the editor view can be theme-exact.
The README says so instead of promising this would fix it.

Two things the new tests establish, both assumptions the code was already
making: all files in a result share the origin's legend, so decoding tokens
from every file against one legend is sound; and all 237 relocated tokens in
the Profiler search report the same type name as their source token.

Also relaxes an over-specific assertion: DotRush calls Profiler.Frames a
field, not a property. Either way it is a member, which is what matters.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

README.md

@@ -47,9 +47,10 @@ and no compilation behind it. So the tokens are fetched for each *source* file i
 results-document coordinates — the same line and column mapping the extension already uses to place the
 highlights. The colouring you get is the server's own answer, moved, rather than a guess.
 
-This happens after the results are on screen and only ever changes colors, never text, so nothing waits on it.
-Set `coloredReferences.semanticTokens` to `false` for TextMate-only coloring. Results spanning more than 40
-files skip it.
+In the editor view this happens after the results are on screen and only ever changes colours, never text, so
+nothing waits on it. The panel gets the same token *types* but paints them from its own palette, since a
+webview is not given the theme’s token colours. Set `coloredReferences.semanticTokens` to `false` for
+grammar-only colouring; results spanning more than 40 files skip it.
 
 ## Settings
 
@@ -57,8 +58,8 @@ files skip it.
 - `coloredReferences.panelLocation` — where the panel opens: `bottom` (default, docked next to Terminal /
   Problems and draggable to a side bar), `beside` (editor group to the side), or `below` (editor group
   underneath, so the table is wide and short)
-- `coloredReferences.semanticTokens` — color the editor view with semantic tokens fetched from the source
-  files (default `true`)
+- `coloredReferences.semanticTokens` — colour identifiers by what the language server says they are, in
+  both views (default `true`)
 - `coloredReferences.openBeside` — open results beside the current editor (default `true`)
 - `coloredReferences.showProject` — show the containing project in file headers (default `true`)
 - `coloredReferences.reuseTab` — reuse one results tab/panel instead of opening a new one per search (default `true`)
@@ -87,9 +88,10 @@ the expected results stay deterministic.
 ## Known limitations
 
 - The panel's code column cannot use your theme's token colors: webviews are not given them as CSS variables.
-  It classifies code with a small tokenizer of its own and paints it with approximated Dark+/Light+ hues, so
-  it will not match your theme exactly. Semantic tokens do not fix this — they supply the *classification*
-  ("this is a class"), never the colors — so only the editor view can be theme-exact.
+  *What* each token is comes from the language server, so `Profiler.Frames.Count` is correctly a class then two
+  properties — but the hues are approximated Dark+/Light+ values, so a custom theme will not match exactly.
+  Only the editor view can be theme-exact. Without a server that serves semantic tokens the panel falls back to
+  a small regex tokenizer, which does guess that any capitalised identifier is a type.
 - Read/write kind is not part of the reference request, so it is derived two ways. Every reference is first
   classified from the surrounding text (assignment and compound-assignment operators, `++`/`--`, `ref`/`out`
   arguments), then `textDocument/documentHighlight` is asked per file and its `Read`/`Write` kinds override
@@ -104,8 +106,7 @@ the expected results stay deterministic.
 
 1. ~~Webview panel with resizable, sortable columns~~ — done; missing: virtualized rendering for very large
    result sets, and remembering column layout per workspace rather than per panel
-2. ~~Semantic token overlay~~ — done for the editor view; the panel still uses its own tokenizer
+2. ~~Semantic token overlay~~ — done in both views
 3. Filter by project / exclude tests
 4. ~~Read/write kind~~ — done in both views
-5. Feed the panel's code column the real token types instead of its regex tokenizer (colors would still be
-   the approximated palette, but the classification would be right)
+