Connected to #10312

Changes made

• Simplifies the setup for all query factory functions related to the getMetadataAsJSON function

Problems and future pitfalls

Unfortunately, while the runtime code is cleaner and no longer requires the query client, there's still a problem, which is that it's hard to make React Query and TypeScript happy.

Every single factory function must have an explicit return type, or else there is a risk of the undefined case from getMetadataAsJSON will pollute the query cache's types. It has to be an explicit return type (and not something like satisfies or no type annotations at all), because the return type needs to do some implicit type casting.

Let's say we have a component like this:

function MyComponent () {
  const appearanceQuery = useQuery(appearance());
  if (appearanceQuery.isSuccess) {
    const data = appearanceQuery.data;
  }
}

This is the type that data will be with each approach for typing the appearance function:

• No type annotations whatsoever - Has type AppearanceConfig | undefined - The cache's types got polluted
• satisfies - Has type AppearanceConfig | undefined - The cache's types still got polluted, because the underlying type didn't change
• as const satisfies - Has type AppearanceConfig | undefined - Even with the object being treated as more of a type literal, the underlying type still doesn't change enough
• Explicit return type – Has type AppearanceConfig - No pollution. This is the only option that works, because the explicit return type is overriding the type that the object would normally be

It's a weird position to be in, where there's only one right way to set up the factory, or else we basically break React Query's internal type system

Next steps

This PR is meant to be more of a stopgap until we figure out a way to avoid these type issues in a more permanent way