Support nullable callbacks in useLiveInfiniteQuery

[KyleAMathews]

Problem

The first-party useLiveQuery adapters allow a query callback to return null or undefined to disable the query. useLiveInfiniteQuery does not: React, Vue, and Svelte reject nullable callback results.

PR #1724 makes the current rejection consistent and tests it across all three adapters, but this remains a public API gap. The infinite-query RFC in #1623 calls for disabled-query support and disabled/enabled transitions.

Desired contract

Support nullable query callbacks in every first-party infinite-query adapter:

useLiveInfiniteQuery(
  (q) => (enabled ? q.from({ todos }).orderBy(({ todos }) => todos.id) : null),
  { pageSize: 20 },
  [enabled],
)

While disabled, match the existing controller and useLiveQuery conventions:

• status is disabled
• isEnabled is false
• isReady is true
• data, pages, and pageParams are empty
• hasNextPage and isFetchingNextPage are false
• error is undefined
• fetchNextPage() is a no-op Promise<void>

Acceptance criteria

• React, Vue, and Svelte types accept callbacks returning QueryBuilder | null | undefined.
• Initially disabled queries do not create or subscribe to a collection.
• Disabled → enabled starts the current query with one committed page.
• Enabled → disabled releases the controller, subscription, and shared window lease.
• Disabling after loading several pages clears the exposed page state.
• Re-enabling starts again at one page rather than reviving stale page depth.
• Disabling during an in-flight page fetch cannot commit or publish stale results.
• Shared conformance tests cover initial disable, enable, disable, re-enable, in-flight disable, cleanup, and public types in all three adapters.
• The shared input policy owns nullable-result handling; framework adapters only unwrap reactive inputs and manage lifecycle.

Scope

This issue covers nullable callback results. A separate config-object API such as { enabled: false } can be designed independently.

Related: #1623, #1724