fix(feed): clamp lounge page pagination

[Zekbot001]

Summary

• route the server-rendered lounge feed page through the existing bounded parsePageParam helper
• prevent negative, non-finite, fractional, or extreme page values from producing unsafe Supabase ranges
• add explicit regression coverage for a non-finite page value

Fixes #358.

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

Verification

• .\node_modules\.bin\vitest.CMD run src/lib/pagination.test.ts
• .\node_modules\.bin\eslint.CMD src/app/feed/page.tsx src/lib/pagination.test.ts
• git diff --check

Existing upstream check blockers

• .\node_modules\.bin\tsc.CMD --noEmit reaches unrelated existing errors in src/app/api/affiliates/offers/route.test.ts:53 and src/app/api/applications/[id]/route.test.ts:21.
• corepack pnpm run build compiles successfully and progresses through static generation when given a process-local dummy OpenAI key, then stops because the local checkout has no Supabase service-role configuration.

[greptile-apps]

Greptile Summary

This PR routes the lounge feed page's page search parameter through the existing parsePageParam helper, preventing unsafe Supabase offset calculations when the parameter is "Infinity", negative, or otherwise invalid. Two regression tests are added to confirm both "Infinity" and "-Infinity" strings are clamped to page 1.

• src/app/feed/page.tsx: Single-line swap from Number(resolvedParams.page) || 1 (which passed Infinity through) to parsePageParam(resolvedParams.page), which uses parseInt + Number.isFinite + Math.min/Math.max to produce a safe, bounded integer.
• src/lib/pagination.test.ts: Two new assertions cover the "Infinity" and "-Infinity" string inputs, completing regression coverage for the Supabase range-overflow bug fixed in Clamp invalid lounge feed page values before Supabase range queries #358.

Confidence Score: 5/5

Safe to merge — a minimal, targeted fix with full regression test coverage and no new risk surface.

The change is a single-line swap to a well-tested, already-in-use helper. The helper's output is provably bounded (integer 1–1000), so the Supabase .range() call can no longer receive a non-finite offset. New tests confirm the previously missing "Infinity" and "-Infinity" input paths.

No files require special attention.

Important Files Changed

Filename	Overview
src/app/feed/page.tsx	Replaces unsafe `Number(resolvedParams.page)
src/lib/pagination.test.ts	Adds regression tests for "Infinity" and "-Infinity" string inputs; both correctly return 1 via the existing !Number.isFinite guard on parseInt output.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A["searchParams.page (string | undefined)"] --> B["parsePageParam(value)"]
    B --> C["parseInt(value || '1', 10)"]
    C --> D{Number.isFinite?}
    D -- No (NaN / Infinity) --> E["return 1"]
    D -- Yes --> F["Math.max(parsed, 1)"]
    F --> G["Math.min(result, 1000)"]
    G --> H["safe page integer (1–1000)"]
    H --> I["offset = (page - 1) * limit"]
    I --> J["supabase .range(offset, offset + limit - 1)"]

Loading

_{Reviews (2): Last reviewed commit: "test(feed): cover negative infinity page..." | Re-trigger Greptile}

[greptile-apps]

Same unsafe pattern exists in two other files — src/components/search/SearchResults.tsx (line 37) and src/app/api/gigs/route.ts (line 27) still use Number(searchParams.get("page")) || 1, which has the same Infinity-bypass that this PR fixes here. Those pages are not part of this diff but share the identical pre-fix behaviour.