fix(auth): read full page number from listUsers Link header

[Lastrixxs]

🔍 Description

Fixes a pagination bug in GoTrueAdminApi.listUsers(). The page number from the Link header was parsed with .substring(0, 1), which truncates any multi-digit page to its first digit — so nextPage/lastPage become wrong once results pass page 9 (e.g. page=10 → 1). This reads the full page value instead.

What changed?

The Link-header page-number parse used .substring(0, 1), keeping only the first character. Replaced it with a match that reads the full page value. The same parse appears twice in the file (listUsers and the OAuth-clients lister); both are fixed.

packages/core/auth-js/src/GoTrueAdminApi.ts:

- const page = parseInt(link.split(';')[0].split('=')[1].substring(0, 1))
+ const page = parseInt(link.split(';')[0].match(/[?&]page=(\d+)/)?.[1] ?? '', 10)

Why was this change needed?

listUsers() derives data.nextPage / data.lastPage from the Link header, but .substring(0, 1) truncates any multi-digit page number to its first digit: page=10 → 1, page=23 → 2. A caller looping on nextPage jumps backwards / loops once results pass page 9 — silently, with no error. At the default per_page of 50 that is any project with more than ~450 users.

Repro:

// > 9 pages of users (e.g. 500 users at per_page 50)
const { data } = await supabase.auth.admin.listUsers({ page: 9, perPage: 50 })
console.log(data.nextPage) // expected 10, actual 1

Behaviour for a single-page response (no Link header) is unchanged.

📸 Screenshots/Examples

Link header	nextPage before	after
page=2	2	2
page=10	1 ❌	10 ✅
page=23	2 ❌	23 ✅

🔄 Breaking changes

• This PR contains no breaking changes

📋 Checklist

• I have read the Contributing Guidelines
• My PR title follows the conventional commit format: <type>(<scope>): <description>
• I have run pnpm nx format to ensure consistent code formatting
• I have added tests for new functionality (if applicable)
• I have updated documentation (if applicable)

📝 Additional notes

The identical parse exists in two methods in this file; both are fixed. The bug only affects the nextPage/lastPage metadata — data.users is correct — so only consumers relying on nextPage past page 9 are impacted.