Search: spinner indicator + performance note on client-side filtering (#32)

- Fix filter fetch to request limit=100 (API max) instead of 500, which
  the API silently clamped, so filtered results actually cover the fetch window.
- Document client-side filtering behavior and limits in README Performance Notes.

README.md

@@ -79,6 +79,16 @@ curl -X POST http://localhost:8080/api/pastes \
 
 Full API docs: [docs/API.md](docs/API.md).
 
+## Performance Notes
+
+The history and Saved pages use client-side filtering: when you type in the
+search box, the UI fetches the most recent 100 pastes (`limit=100`, the API
+maximum) once per query and filters/sorts them in the browser. Pastes beyond
+the newest 100 are not searched; a match count against the full total is still
+shown. This keeps search instant without a server-side query. If large
+instances need full search later, it will be a server-side endpoint (see
+issue #32).
+
 ## CI
 
 Gitea Actions workflow at `.gitea/workflows/ci.yml`:

internal/web/static/table.js

@@ -63,7 +63,7 @@ const PaletteTable = (() => {
         const filtered = state.filter.length > 0;
         const off = (state.page - 1) * opts.perPage;
         const url = (filtered || state.sortKey)
-          ? opts.endpoint + '?limit=500&offset=0'
+          ? opts.endpoint + '?limit=' + (opts.fetchLimit || 100) + '&offset=0'
           : opts.endpoint + '?limit=' + opts.perPage + '&offset=' + off;
         const res = await fetch(url);
         const data = await res.json();