Checked how _optimisticResults actually gets consumed in queryObserver.ts to confirm setting it to undefined is the right lever here, not just a workaround. The whole "optimistically set result in fetching state" block in getOptimisticResult is gated by if (options._optimisticResults), so making it undefined when subscribed is false skips that block entirely rather than trying to override its output afterward, the query's reported state stays whatever it genuinely is instead of getting bumped into a fabricated fetching appearance for something that was never going to fetch in the first place, since shouldSubscribe already gates the actual observer subscription on the same subscribed flag.

While I was in there I checked whether this same gap exists in the sibling adapters, since _optimisticResults and the subscribed option show up in basically every framework package here. preact-query/src/useQueries.ts still has the unconditional version, defaultedOptions._optimisticResults = isRestoring ? 'isRestoring' : 'optimistic', no subscribed check at all, same exact bug this PR fixes for react-query. Not something to fix in this PR, just flagging since preact-query tends to mirror react-query closely and this looks like it'd need the identical treatment.

Test is well targeted, it asserts queryFn was never called, the query has zero observers, and both isFetching/fetchStatus read as idle, which covers the actual bug (a misleading loading UI for a query that was never subscribed) rather than just checking one symptom of it.