Add multi-parquet Shiny test, clean up stale plan doc text

Author: glin

design/duckdb-wasm-engine/duckdb-wasm-engine-test.Rmd

@@ -947,6 +947,54 @@ server <- function(input, output, session) {
 shinyApp(ui, server)
 ```
 
+### Multiple Parquet tables in Shiny
+
+Test that multiple Parquet-backed tables on the same Shiny page resolve their sidecar
+files independently. Each table has its own `parquetId` and locator script, so the
+querySelector fallback must use a table-specific selector (not just `parquet-locator`).
+
+Test steps:
+1. Both tables should render with correct data.
+2. Sorting and filtering should work independently on each table.
+3. Check browser console for errors (wrong Parquet URL would cause a fetch failure).
+
+```{r eval=FALSE}
+library(shiny)
+library(reactable)
+
+ui <- fluidPage(
+  h3("Multiple Parquet tables in Shiny"),
+  h4("Table 1: mtcars"),
+  reactableOutput("table1"),
+  h4("Table 2: iris"),
+  reactableOutput("table2")
+)
+
+server <- function(input, output, session) {
+  output$table1 <- renderReactable({
+    reactable(
+      mtcars,
+      backend = backendDuckDB(mode = "client", format = "parquet"),
+      defaultPageSize = 10,
+      sortable = TRUE,
+      filterable = TRUE
+    )
+  })
+
+  output$table2 <- renderReactable({
+    reactable(
+      iris,
+      backend = backendDuckDB(mode = "client", format = "parquet"),
+      defaultPageSize = 10,
+      sortable = TRUE,
+      filterable = TRUE
+    )
+  })
+}
+
+shinyApp(ui, server)
+```
+
 ### Arrow IPC in Shiny (client mode)
 
 Test that embedded Arrow IPC works in a Shiny app with DuckDB client mode.

design/server-side-data/server-side-data.md

@@ -194,8 +194,6 @@ When server-side search returns zero results, pagination shows "1-10 of 0 rows"
 - Parquet sidecar files: same `querySelector` fallback in the Parquet locator script and a runtime URL resolution fallback in `useEffect`
 - Both `format = "arrow"` and `format = "parquet"` work correctly
 - Warning suppressed when user explicitly sets `mode = "client"` (only warns for auto-resolved client mode)
-- This is acceptable behavior matching other table libraries
-- Much simpler than full server-side implementation
 
 **Future simplification: consider removing pre-rendered first page.** The R-side pre-rendering of the first page (to avoid a blank flash while WASM loads) adds significant JS complexity: `canSkipInitialDuckDBQuery`, `duckdbQueryCount`, `stateMatchesPrerender` comparison against `defaultSorted`, the groupBy special case (pre-rendered data is flat so we must query immediately), and race conditions when users interact before DuckDB is ready. Without pre-rendering, the query effect fires unconditionally after init and the entire skip optimization disappears. The tradeoff is showing a loading/empty state during WASM init instead of instant first-page display.