fix(fetchium): resolve TopicQuery adapter via subclass-aware lookup

[jimmy-phantom]

Summary

• TopicQuery now assigns static adapter = TopicQueryAdapter so subclasses inherit a runtime value (mirroring RESTQuery/RESTQueryAdapter). The type stays widened to QueryAdapterClass<TopicQueryAdapter> so subclasses can override with concrete adapters whose constructors take arguments.
• QueryClient.getAdapter() now falls back to an instanceof scan over registered adapters before auto-instantiating, so an abstract base on the query resolves to a consumer-registered concrete subclass.

Why this is needed

Before this change, TopicQuery.adapter was a type-only annotation with no value. That forced every TopicQuery subclass to set static adapter explicitly, which:

1. Blocks code generators that emit TopicQuery subclasses without knowing which concrete adapter the consumer will register. The generated classes can only target the abstract base.
2. Forces hand-authored subclasses to write a double-cast (as unknown as typeof TopicQueryAdapter) when their adapter has constructor args, because the override has to match the abstract base shape.

Why subclass-aware lookup is needed for topics but not REST

RESTQueryAdapter is concrete, so consumers register new RESTQueryAdapter(...) directly — the registered instance's .constructor equals the static-adapter key on the query, and exact-match lookup hits.

TopicQueryAdapter is abstract (subscribe/unsubscribe are abstract). Consumers must register a subclass instance (e.g. a WebSocket-backed adapter), so the registered .constructor is the subclass, not the base. Without the subclass-aware fallback, getAdapter(TopicQueryAdapter) misses, falls through to auto-instantiation, and throws because you can't new an abstract class.

The instanceof fallback also makes the REST path correct in the (previously undefined) case where a consumer registers a subclass of RESTQueryAdapter — the old code would silently auto-instantiate a fresh RESTQueryAdapter and ignore the registered instance.

Test plan

• npm run check-types passes (existing adapter-types.test-d.ts still validates the override surface).
• All unit + react tests pass in CI (1221 passing on the second attempt; the first attempt hit a flaky react/__tests__/basic.test.tsx:658 "Loading vs 0" timing assertion unrelated to this change — getAdapter's fast-path is unchanged when an exact-match adapter is registered).
• New unit test in topic-query.test.ts covers a TopicQuery subclass that does not set static adapter, asserting (a) the inherited static value is TopicQueryAdapter and (b) fetchQuery() resolves via the registered subclass instance.

🤖 Generated with Claude Code