diff --git a/client/src/tiles.ts b/client/src/tiles.ts
index 4d85f70..cd6be9d 100644
--- a/client/src/tiles.ts
+++ b/client/src/tiles.ts
@@ -140,11 +140,14 @@ export function renderTilesInChunks(container: HTMLElement, items: ItemDto[], ch
  * Wires a search <input> to show/hide `itemSelector` elements by name,
  * live as you type - client-side only, filtering whatever's already
  * rendered rather than a server round trip per keystroke. Deliberately
- * simple for that reason: a library page tops out at a few hundred items
- * (see getLibraryItems's own Limit), well within "just filter the DOM"
- * territory - shared by views/library, views/artist, views/album so the
- * three catalog pages that asked for this all behave identically instead
- * of drifting into three slightly different implementations.
+ * simple for that reason: even a library with well over a thousand items
+ * (see getLibraryItems/getArtists - no Limit any more, see their own
+ * comments) is still just a plain, already-in-the-DOM list of elements
+ * to a querySelectorAll/textContent check - "just filter the DOM" scales
+ * fine here regardless of count. Shared by views/library, views/artist,
+ * views/album so the three catalog pages that asked for this all behave
+ * identically instead of drifting into three slightly different
+ * implementations.
  *
  * `scope` should be wide enough to contain both the items themselves AND
  * a `.searchEmpty` notice element - typically the view's own `root`, not
diff --git a/docs/architecture.md b/docs/architecture.md
index c3b6cf4..5318e4e 100644
--- a/docs/architecture.md
+++ b/docs/architecture.md
@@ -2631,6 +2631,28 @@ mode a naive per-button-at-call-time wiring would have hit). **Not
 verified**: no Emby login reachable from this sandbox to measure the
 actual before/after latency against a real, large library.
 
+**Correction, reported immediately after this shipped**: "the catalogs
+are broken, not all the data is there". The `Limit: 300` both queries
+above carried (`getArtists` gained one here; `getLibraryItems` already
+had one, predating this section) turned out not to be the safe,
+theoretical headroom it was assumed to be - confirmed directly against
+the real server that this app's own "Musique" library has **1229**
+distinct artists and "Films" has **421** movies, so both were silently
+serving an incomplete grid, no error, no visible sign anything was
+missing. Both `Limit`s removed outright, not raised to some other
+guessed number - confirmed empirically that Emby returns everything
+when `Limit` is omitted at all (`TotalRecordCount` matched
+`Items.length` exactly for both the 421- and 1229-item cases), and the
+render-side concern that motivated capping in the first place is
+already `renderTilesInChunks`'s job regardless of how large the list
+gets. That fix's own scheduling primitive needed a second look too:
+`requestAnimationFrame` is deliberately paused by the browser for a
+backgrounded/hidden tab - an ordinary thing to do while a now-possibly-
+1000+-item list is still loading, and would have stalled the render
+indefinitely, looking exactly like the same "data missing" symptom for
+an unrelated reason. Switched to `setTimeout(fn, 0)`, which keeps
+running (throttled, never paused) regardless of tab visibility.
+
 ## Fixing the listen-party queue's layout and its missing album art
 
 Reported directly: the music bar's "File d'attente" popup looked broken,