fix(search): normalize client pagination state

[Zekbot001]

Summary

• normalize /search?page= before client state and fetches use it
• keep the UI pagination state aligned with the API route's finite positive page bounds
• add a component regression test for negative URL page values

This is a distinct follow-up to #325: that PR clamps the API route, while the search component could still render impossible page numbers from the URL.

Paid task: https://ugig.net/gigs/abd6b2a0-e728-48cf-a46f-f99e419ed94e

Testing

• corepack pnpm exec vitest run src/components/search/SearchResults.test.tsx
• corepack pnpm exec eslint src/components/search/SearchResults.tsx src/components/search/SearchResults.test.tsx
• git diff --check
• corepack pnpm type-check (blocked by pre-existing errors in src/app/api/affiliates/offers/route.test.ts and src/app/api/applications/[id]/route.test.ts)
• corepack pnpm build (compiles successfully, then page-data collection is blocked by missing OPENAI_API_KEY for /api/profile/import)

[greptile-apps]

Greptile Summary

This PR normalizes the page URL parameter in the SearchResults component by routing it through the shared parsePageParam utility (clamping to [1, 100 000]) and calling router.replace whenever the raw value differs from the clamped one, so the address bar stays consistent with what was actually fetched.

• SearchResults.tsx: Replaces the ad-hoc Number(...) || 1 expression with parsePageParam, adds a router.replace normalization step inside the main effect, and updates the dependency array accordingly.
• SearchResults.test.tsx: Adds a new test that renders the component with ?page=-4 and asserts that the API call uses page=1 and that router.replace is called with the cleaned URL.

Confidence Score: 5/5

Safe to merge — the normalization logic is correct, the test covers the key regression, and no incorrect data is ever displayed.

The clamping and URL-replacement logic is straightforward and correct. The only notable side-effect (a redundant second fetch when the URL is normalized) does not produce wrong data or visible bad state in practice — both fetches use identical parameters and return identical results. The change is narrow in scope and well-tested.

No files require special attention.

Important Files Changed

Filename	Overview
src/components/search/SearchResults.tsx	Adds parsePageParam clamping and a router.replace normalization step in the main effect; the effect continues to fetch in the same run as the replace, which can produce a redundant fetch after the URL update causes a re-render.
src/components/search/SearchResults.test.tsx	New regression test verifying fetch URL normalization and router.replace call for a negative page value; covers the primary scenario correctly.

Sequence Diagram

sequenceDiagram
    participant Browser
    participant SearchResults
    participant router
    participant API

    Browser->>SearchResults: "Mount with ?page=-4"
    SearchResults->>SearchResults: parsePageParam("-4") → 1
    Note over SearchResults: rawPageParam ≠ String(pageParam)
    SearchResults->>router: "replace("/search?q=...") [no page param]"
    SearchResults->>API: "fetch /api/search?page=1&..."
    API-->>SearchResults: "{ page:1, total:20, ... }"
    SearchResults->>Browser: Render "Page 1 of 2"
    router-->>SearchResults: searchParams updated (URL now clean)
    SearchResults->>SearchResults: "Effect re-fires (rawPageParam = null)"
    SearchResults->>API: "fetch /api/search?page=1&... (2nd, redundant)"
    API-->>SearchResults: Same data
    SearchResults->>Browser: Re-render (loading flash possible)

Loading

_{Reviews (2): Last reviewed commit: "fix(search): replace malformed paginatio..." | Re-trigger Greptile}