docs: anchor RC migration guidance to DB 0.9.2

docs/collections/query-collection.md

@@ -871,8 +871,7 @@ window. It does not run TanStack Query's `InfiniteQueryObserver`. Query
 Collections use `QueryObserver`, so `queryFn` receives
 `meta.loadSubsetOptions`, not `pageParam`.
 
-The previously ignored `getNextPageParam` option has been removed. Delete it
-from your hook config; passing it at runtime now throws a clear error.
+`getNextPageParam` is not supported; passing it at runtime throws an error.
 `initialPageParam` labels result pages only. It does not set a remote offset
 or server cursor.
 

docs/framework/react/overview.md

@@ -182,7 +182,7 @@ const { data, pages, fetchNextPage, hasNextPage } = useLiveInfiniteQuery(
 `fetchNextPage()` returns a promise that resolves after the page request settles. A failed page load does not reject the promise or change `status`; it appears as a request error in the returned `health` tree.
 
 This hook widens an ordered live query; it is not TanStack Query's
-`useInfiniteQuery`. `getNextPageParam` was previously ignored and is now rejected.
+`useInfiniteQuery`. `getNextPageParam` is not supported.
 `initialPageParam` only labels the returned pages; it does not set a server cursor
 or skip remote rows. For server pagination, use an on-demand Query Collection
 whose `queryFn` fulfills `meta.loadSubsetOptions`. See the

docs/guides/error-handling.md

@@ -662,20 +662,17 @@ sync: ({ begin, write, commit, markReady, reportError, fail, reportHealthy }) =>
 
 ### Migrating
 
+If you're upgrading from 0.9.2 to the 1.0 RC, update your error handling as
+shown below. For the other breaking changes, see
+[Migrating to the 1.0 RC](./migrate-to-1-0-rc.md).
+
 | Before | After |
 | --- | --- |
 | `isError` | `isLoadingError` (first load failed) or `isCrashed` (storage broke) |
 | `status: 'error'` after a crash | `status: 'crashed'` |
 | `markError(error)` | `fail(error)` |
-| `reportError(error, { final })` | `reportError(error)` or `fail(error)` |
-| node `phase`, `final`, `isError` | node `failureReason` or `error` |
-| node `instances` | removed |
 | `cleanup()` then `preload()` to recover | `reload()` |
-| `begin({ direct: true })` | `begin()`: every write applies on the kept rows |
-| a reload's first commit replaced every row | `begin({ snapshot: true })` or `truncate()` replaces them |
-| `markReady()` after `fail()` threw | it does nothing |
 | `cleanup()` with live queries mounted | rejects; unmount first or `cleanup({ dependents: true })` |
-| `persistedStatus`, `isPersistedReady`, `persistedError`, `preloadForInitialRender()` | `status` and `health` |
 | query-db `utils.lastError`, `isError`, `errorCount`, `clearError()` | `health`, `reload()` |
 
 ## Transaction Error Handling

docs/guides/live-queries.md

@@ -2104,8 +2104,9 @@ const page2Users = createLiveQueryCollection((q) =>
 
 ## Pooled Live Queries
 
-Apps that mount many live queries of the same shape at once, such as one per
-list row, can share their work. Pass `pooledLiveQueries` as `pool` in a hook's
+Pooling is an optional performance feature for screens with dozens or more
+live queries of the same shape, such as one per list row. These queries can
+share their work. Pass `pooledLiveQueries` as `pool` in a hook's
 query config. Queries that filter one eager source with `eq(field, literal)`
 then read one shared partition instead of compiling a graph each: