docs: say what changes instead of re-render in Solid's own sense

Rows are recreated, lists are rebuilt, nothing updates; the server renders
the page again after a no-JavaScript post. The Lists heading and its
reference links change together. Also restores the extractor's formatting
on three reference pages that prettier had touched.

Co-authored-by: Cursor <cursoragent@cursor.com>

Author: ryansolid

scripts/extract-solid-ref.mjs

@@ -1778,8 +1778,8 @@ const LIST_PROBLEMS = {
 		"/guides/lists#a-row-shows-the-wrong-index-after-reordering",
 	],
 	wholeList: [
-		"Editing one item re-renders the whole list",
-		"/guides/lists#editing-one-item-re-renders-the-whole-list",
+		"Editing one item rebuilds the whole list",
+		"/guides/lists#editing-one-item-rebuilds-the-whole-list",
 	],
 	pushNothing: [
 		"`items.push(item)` does nothing",

src/routes/(2)concepts/(3)async-reactivity.mdx

@@ -408,7 +408,7 @@ A loading boundary does not consume errors, and an error boundary does not repla
 
 An error is a status of that part of the graph, not a terminal state.
 When the data underneath changes, because an input signal changed or a `refresh` landed, the boundary retries and the content returns.
-`reset` retries the failed sources rather than re-rendering the same error.
+`reset` retries the failed sources rather than showing the same error again.
 [Boundaries](/concepts/boundaries) covers placement and recovery in detail.
 
 ## Read every input before the first `await`

src/routes/(2)concepts/(5)mutations.mdx

@@ -103,7 +103,7 @@ Three things were added:
 The optimistic write is an overlay on the durable store, not a second copy of the state.
 Solid discards the overlay when the action settles, whether the action succeeded or failed.
 If `api.add` throws, the overlay is dropped and the list is back where it started; there is no rollback code to write.
-If the server agrees with the prediction, reconciliation finds no differences and nothing re-renders.
+If the server agrees with the prediction, reconciliation finds no differences and nothing updates.
 
 Because actions ride the same hold as reads, the list never shows half a mutation, and quick repeated clicks do not interleave into a corrupted list.
 

src/routes/(3)building-apps/(3)server-functions/(5)progressive-enhancement.mdx

@@ -71,7 +71,7 @@ Before hydration, the `Avoid` version has no handler attached, so the click does
 
 Everything the hydrated page does with a submission is a layer over that post.
 Once the router is running it intercepts the submit, calls the same function over the server-function transport, sets `aria-busy` on the form while the call runs, records the result in `useSubmissions`, and runs any `.onSubmit` hook before the call is sent, which is where an [optimistic write](/routing/solid-router/data#before-the-server-confirms) goes.
-None of that changes the HTML or the server function, so a shopper whose bundle has not arrived gets the post and the re-render, and a shopper whose bundle has arrived gets the same result painted before the server answers.
+None of that changes the HTML or the server function, so a shopper whose bundle has not arrived gets the post and a fresh page, and a shopper whose bundle has arrived gets the same result painted before the server answers.
 
 The [Forms guide](/guides/forms) builds the checkout address form on this shape, with validation messages, pending state, and an address list that updates before the server confirms.
 

src/routes/(4)routing/(1)solid-router/(5)data.mdx

@@ -363,7 +363,7 @@ When the action finishes, the `reload` revalidates `getCart`, the store reconcil
 Registering `.onSubmit` inside a component ties the hook to that component's lifetime.
 
 The form did not change to get this.
-Before hydration it is the same `POST` as in [Mutate with actions](#mutate-with-actions): the browser submits, the server runs `addToCart`, and the page re-renders with the cart from the database.
+Before hydration it is the same `POST` as in [Mutate with actions](#mutate-with-actions): the browser submits, the server runs `addToCart`, and the server renders the page again with the cart from the database.
 After hydration the router intercepts the submit, runs the `.onSubmit` hooks as the first step of the action's transaction, sends the call, and reconciles the revalidated data over the prediction.
 The optimistic layer is something the hydrated page adds on top of a form that already works; the server function and the HTML are the same in both cases.
 

src/routes/(5)guides/(10)debugging-reactivity.mdx

@@ -188,7 +188,7 @@ Return the same reference when nothing changed, keep the data in a store, or pas
 
 ### A write replaces an object that did not change
 
-`setItems(await fetchItems())` replaces every item with a new object, so every row that reads an item re-renders.
+`setItems(await fetchItems())` replaces every item with a new object, so every row that reads an item is recreated.
 Use a store with `reconcile` to merge the new data into the existing objects, so only the properties that changed notify their readers.
 See [Stores](/concepts/stores).
 
@@ -320,7 +320,7 @@ Server render is pure: state changes flow from async sources (promises, async it
 ```
 
 A server render is one pass from inputs to HTML.
-A setter called during that pass lands as inert data and nothing re-renders, so the write is a sign the code expects a client-side update loop that does not exist on the server.
+A setter called during that pass lands as inert data and nothing updates, so the write is a sign the code expects a client-side update loop that does not exist on the server.
 The fix depends on what the write was for:
 
 - Bridging a subscription or a promise into a signal: make the source itself the value, `createSignal(() => source)` or `createStore(async () => ..., seed)`, so both server and client read it the same way.

src/routes/(5)guides/(4)forms.mdx

@@ -471,7 +471,7 @@ Use `throw respond(value, { status })` for structured failures.
 - Read failures from `useSubmissions(action)`, where the envelope's value is `submission.error`.
 - Style the pending state from `form[aria-busy]`; the router sets and clears the attribute.
 - Push the submitted fields into a `createOptimisticStore` from the action's `.onSubmit` hook to show the result at once; the overlay is discarded when the action settles and the revalidated list replaces it.
-- Every layer after pass 1 exists only on the hydrated page; the same form still posts and re-renders without JavaScript.
+- Every layer after pass 1 exists only on the hydrated page; the same form still posts, and the server renders the page again, without JavaScript.
 
 ## Next steps
 

src/routes/(5)guides/(5)lists.mdx

@@ -295,7 +295,7 @@ Key by a field or load into a store; see [Keep row identity across updates](#kee
 The callback captured `index()` once instead of reading it in JSX.
 Read `index()` inside the JSX expression so it stays reactive, or use `keyed={false}` when the row should be bound to its position rather than its item.
 
-### Editing one item re-renders the whole list
+### Editing one item rebuilds the whole list
 
 The list is an array of plain objects in a signal, and the edit replaced the array or the object.
 Move the list into a store and mutate the draft.

src/routes/(5)guides/(8)ssr-safe-code.mdx

@@ -81,7 +81,7 @@ A `const` at the top of a file is evaluated once when the server entry loads and
 
 :::caution[A setter called during a server render lands as inert data]
 A server render is one pass from inputs to HTML.
-Calling `setOpen(true)` in the component body on the server does not re-render anything, and development prints a `[SERVER_WRITE]` warning the first time it happens.
+Calling `setOpen(true)` in the component body on the server updates nothing, and development prints a `[SERVER_WRITE]` warning the first time it happens.
 [A write on the server did nothing](/guides/debugging-reactivity#a-write-on-the-server-did-nothing) explains the warning and what the write should have been.
 :::
 

src/routes/reference/(1)solid-js/(2)stores/create-store.mdx

@@ -138,7 +138,7 @@ an `ssrSource` field
 ## Common problems
 
 - [`items.push(item)` does nothing](/guides/lists#itemspushitem-does-nothing)
-- [Editing one item re-renders the whole list](/guides/lists#editing-one-item-re-renders-the-whole-list)
+- [Editing one item rebuilds the whole list](/guides/lists#editing-one-item-rebuilds-the-whole-list)
 - [Something does not update](/guides/debugging-reactivity#something-does-not-update)
 
 ## Learn more