web: clamp file manager currentPage against totalPages to survive content shrink

[cswaney]

Context

#500 (fix/429) resets `currentPage` to 1 when `path` or `query` changes in `FileManagerTable.jsx`, mirroring the precedent set in `AudioFileBrowser` (#427). That covers directory navigation and filter changes, but it leaves one bug class open: the current page can point past the last page when `content` itself shrinks without `path` or `query` changing.

Repro

1. Filter to ~11 matches so pagination shows 2 pages.
2. Navigate to page 2.
3. Delete all files on page 2.
4. `refresh()` in `FileManager.handleDeleteSuccess` updates `content` but does not touch `path`/`query`, so the reset effect from fix(web): reset file manager to page 1 on directory or filter change #500 does not fire.
5. Result: `currentPage` still points to 2, but `totalPages` is now 1 — the table renders a blank page until the user manually clicks back.

Upload-shrinks-page-count is theoretically the same shape but less likely in practice.

Proposed fix

Rather than enumerating every trigger that can shrink the list, clamp at render:

```js
const totalPages = Math.max(1, Math.ceil(sortedContent.length / filesPerPage));
const effectivePage = Math.min(currentPage, totalPages);
```

That covers path/query/delete/upload uniformly without relying on the effect's dependency list staying in sync with every state that can affect list length.

Scope

• Apply the clamp in `web/src/components/file-manager/FileManagerTable.jsx`.
• Consider the same fix in `AudioFileBrowser.jsx` (pre-existing, same shape — see fix(web): show pagination in the audio file browser #427).
• Regression tests: delete-last-row-on-last-page for `FileManager` (and audio equivalent if we touch it), assert that the visible page falls back to a valid one.

Notes

• Surfaced during bot review of fix(web): reset file manager to page 1 on directory or filter change #500. Non-blocking there; keeping the fix small and focused. This issue tracks the broader clamp.