feat(solid_generator): cross-instance @SolidQuery consumption in build()

[nank1ro]

What

A widget's build() can now read another class's @SolidQuery method cross-instance — e.g. a view reading its injected view model's query:

isLoading: viewModel.customers().isLoading,
error: viewModel.customers().asError?.error,
totalCount: viewModel.customers().asReady?.value.length ?? 0,
onRetry: viewModel.customers.refresh,

Previously only the class declaring a @SolidQuery could consume it, even though cross-instance @SolidState reads already worked. Such a cross-instance query read got no SignalBuilder wrap (not reactive) and no flutter_solidart import (the ResourceState extension accessors did not resolve).

How

• New cross-file query-name registry (classQueryNames), populated for every query-bearing class including pure-query classes with no @SolidState members.
• value_rewriter recognizes receiver.query() (receiver's resolved type is a query-bearing class) as a tracked read — recording the offset only, with no source edit, so the query() call site and the query.refresh tear-off stay byte-identical. The existing computeWrapPlan then wraps the enclosing widget subtree, and the import is spliced in off the emitted-wrap flag.
• The registry is origin-qualified exactly like the @SolidState registry (Name-keyed registry cannot disambiguate a local plain class from a foreign reactive class with the same name #110 parity): an ambiguous simple name resolves only on a receiver's resolved-library match, so a same-named non-query method is never spuriously tracked.

Tests

• New golden cross_file_pure_consumer_widget_query (the core feature) and cross_file_query_qualified_registry_disambiguation (proves a real query is wrapped while a same-named ordinary method on a different class is not), plus idempotency checks.
• Full suite green: 356 tests pass.

Releases solid_generator 3.0.0-dev.6.