fix(fuselage): enlarge pagination controls on small viewports

[anshurajbisoyi98-ctrl]

Proposed changes (including videos or screenshots)

Design clarification pending: This draft enlarges mobile touch targets, but currently wraps page controls onto multiple rows at narrow widths. The issue screenshot uses a single row. Maintainer guidance is requested before choosing a compact page-number layout or another approach.

Increase pagination controls to 44×44px below the medium breakpoint, using the existing size helpers. Page links wrap on narrow viewports, and the items-per-page label sits above its choices so they remain on one row. The compact layout is retained from 768px upward. The 44×44 CSS-pixel target follows the size threshold in WCAG’s enhanced target-size criterion; this is not a claim of overall WCAG AAA conformance. See WCAG target-size guidance.

The current Storybook reproduces the small-control problem: the new browser checks failed at 320px, 375px, and 600px before the style change, with a button width of approximately 15.5px. The checks now verify minimum control dimensions, a single row of items-per-page choices, and absence of horizontal overflow.

The Storybook description documents the responsive behavior, and a patch changeset is included.

Screenshot

Pagination after the fix at a 320px viewport:

Issue(s)

Fixes #194.

Further comments

Validation:

• Monorepo unit tests: 704 passed across 133 suites.
• Pagination unit tests: 3 passed, including the accessibility check and existing snapshot.
• yarn lint passed across the monorepo; unchanged React-hook and build warnings remain.
• The three new browser regression cases failed before the fix and passed afterward.
• Existing default and divider pagination screenshots matched without baseline updates.
• Changed-file formatting, browser-test TypeScript checks, and git diff --check passed.

The full visual run passed 484 of 510 cases initially; 26 cases timed out during page/font loading. All 26 passed on retry using a local server with a larger request queue and two workers, without changing code or updating snapshots.

After increasing targets from 40px to 44px, all five pagination browser checks passed again: three mobile sizes and both unchanged desktop screenshot baselines. The full 510-case visual run above was performed on the earlier 40px revision.

Validation used Node 22.22.3, Yarn 4.18.0, and the repository-pinned Playwright 1.62.1 Linux container on macOS. Other browsers and remote CI have not yet been verified.

AI assistance

Codex assisted with investigation, implementation, tests, local verification and documentation.

[changeset-bot]

🦋 Changeset detected

Latest commit: 2b16d33

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@rocket.chat/fuselage	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[CLAassistant]

All committers have signed the CLA.

[anshurajbisoyi98-ctrl]

The screenshot in #194 keeps the page controls on one row, while my current implementation wraps them on narrow screens. I would like to confirm the intended layout before taking this further.

At 320px, the existing page choices cannot all fit on one row with 44px touch targets and the current padding. Would you prefer fewer visible page numbers on mobile while retaining the previous/next controls, or a different sizing/layout approach? Also, does “too small” refer to the text size as well as the touch targets?

I have marked this PR as a draft while this design choice is pending. The screenshot in the description shows the current proposal.