admin.create_user returns "User not allowed" in v2.28.0 but works in v2.11.0

[MarvinPescos]

Describe the bug

supabase.auth.admin.create_user() fails with "User not allowed" in v2.28.0. The same call works correctly in v2.11.0 with identical code, keys, and Supabase project.
A direct HTTP request to /auth/v1/admin/users using the same service role key and payload via httpx returns 200 OK — confirming the Supabase server and credentials are correct.

Reproduction

from supabase import create_client

client = create_client(SUPABASE_URL, SUPABASE_SERVICE_ROLE_KEY)
client.auth.admin.create_user({
    'email': 'user@example.keta.com',
    'password': 'SecurePass123',
    'email_confirm': True,
})
# Raises: "User not allowed"

Steps to reproduce

1. Install supabase v2.28.0: pip install supabase==2.28.0
2. Create a client with a valid service role key
3. Call client.auth.admin.create_user(...) with any valid email/password
4. Observe: raises "User not allowed"
5. Downgrade: pip install supabase==2.11.0
6. Repeat step 3 — works successfully
7. Raw httpx POST to /auth/v1/admin/users with same key and payload also returns 200

Library affected

supabase-auth

Library version

supabase 2.28.0

Python version

python 3.12

[AdityaMedidala]

I've traced the root cause and am preparing a PR.

When a session exists on the client (e.g. after sign_in_with_password), the Authorization header switches to the session access token. Admin API calls then inherit this token instead of the API key used to construct the client, which causes Supabase Auth to reject the request with "User not allowed". This appears to have been introduced around the refactor that removed the SyncClient classes from supabase_auth in favor of plain httpx.Client, since the older implementation kept admin API headers isolated from session state.

I'll propose a fix in supabase_auth to ensure admin endpoints always use the construction-time API key. Will link this issue in the PR.