`find_implementations` answers `[]` for a class under pyright/pyrefly — fall back to the type hierarchy?

Is your feature request related to a problem? Please describe. With the LSP backend, find_implementations on a Python class returns [] under pyrefly (and pyright answers textDocument/implementation with MethodNotFound): these servers implement the request for methods — the overriding methods of an abstract one — not for the class itself. So "who implements this port / subclasses this base" has no answer, although pyrefly serves textDocument/prepareTypeHierarchy + typeHierarchy/subtypes and answers exactly that (measured: ContainerProvider → ProductionContainerProvider in ~1 s on a 30k-line project).

Describe the solution you'd like

1. When the server reports no implementations for a symbol of kind Class or Interface, fall back to typeHierarchy/subtypes and return those symbols. A server without a typeHierarchyProvider answers MethodNotFound; treat that as an empty hierarchy, never as an error.
2. An optional tool find_type_hierarchy(name_path, relative_path, direction="subtypes"|"supertypes") over the same requests, one level per call, for the LSP backend (the JetBrains backend already has jet_brains_type_hierarchy).

This is a behaviour change for the class case (subtypes instead of []), hence the issue before the PR. I have the change ready with tests (pyrefly: subtypes, supertypes, the fallback; typescript-language-server 5.1.3, which has no type hierarchy: the empty contract).

Describe alternatives you've considered Leaving find_implementations as is and only adding the tool — but agents ask find_implementations about classes constantly and get a silent [].

Additional context pyrefly answers the hierarchy requests with the whole chain (indirect descendants/ancestors too), so the result is documented as "what the server reports" rather than strictly direct. Supertypes outside the repository (typeshed) are skipped.