Make rows per page user-configurable in the translation-string Browse view

## Problem

Browse is the most useful compact view for reviewing a translation catalog because it shows the string key/context alongside the source and translation. This is particularly useful for application developers auditing naming, organization, and wording across the catalog.

Browse currently displays a fixed 20 rows per page. Reviewing a catalog containing hundreds of strings therefore requires repeatedly paging through it; a 473-string catalog requires 24 pages.

Other Weblate surfaces do not provide the same overview:

- Matrix compares languages but does not show string keys.
- Zen expands every string into an editor.
- Weblate’s REST API can return larger batches, and its CSV/XLSX exports can be reviewed externally, but neither provides the compact in-Weblate table with filtering, sorting, and links to individual strings.

## Proposal

Add a bounded rows-per-page selector to the translation-string Browse view.

Carry the selection in the URL so it works without signing in and can be bookmarked or shared. Weblate could additionally remember the selection in an authenticated user’s preferences.

Keep 20 as the default and enforce a reasonable server-side maximum. Filtering, sorting, and pagination should preserve the selected page size.

## Related work

#5535 and #6393 addressed navigation through the regular translation editor. This request is limited to the compact Browse view.

Start at the translation-string Browse view and trace how filtering, sorting, and pagination are handled. Check how URL parameters are parsed and preserved, then verify that a bounded rows-per-page selection keeps 20 as the default and survives filtering, sorting, pagination, bookmarking, and sharing.

Written by the indexing model from the issue text.