6.0.1 — find_symbols no longer fails in Rider

[serialexperimentslainnnn]

Fixes #83.

In Rider, find_symbols failed outright with
UnsupportedOperationException: Use RdChooseByNameContributor.processNamesLifetimed. Rider's symbol
contributors are proxies to the ReSharper backend and refuse the platform's processNames call by
contract; the tool was calling it on every contributor and letting the refusal escape.

What changed

• SymbolSearch isolates each contributor: one that refuses is counted and skipped, as the platform's
  own ContributorsBasedGotoByModel does.
• When the refusals leave nothing to return, find_symbols says how many refused and names what does
  work there (search_text, find_files, file_outline, definition, references,
  implementations). An empty list would read as an empty project or a warming index — verified on
  Rider 2026.2.1, where Claude read exactly that from the first attempt at this fix.
• An answer shortened by a refusal carries partial.

What this does not do

It does not give Rider its .NET symbols back. Those live in the ReSharper backend and only reach
the frontend over its own protocol. The API that would read them,
SymbolSearchEverywhereContributor, is @ApiStatus.Internal, which DIRECTIVES.md forbids;
processNamesLifetimed is Rider's own class, not the platform's. So in Rider the tool now reports
honestly instead of crashing, and points at the tools that work.

Verification

• Rider 2026.2.1 on a real .NET solution: no exception.
• spotlessCheck, test (4877), npm test (681), npm run lint, verifyPlugin (8/8 compatible,
  experimental API only).
• detekt could not run locally (> 25.0.4.1, detekt 1.23.8 against this machine's JDK 25); it runs
  here on JDK 21.

After this merges, main goes back to develop as a hotfix does.

🤖 Generated with Claude Code