feat(scim): add GET /scim/v2/Users/{id}

[xlgmokha]

What kind of change does this PR introduce?

Feature. Adds GET /scim/v2/Users/{id}, the first SCIM resource endpoint.

https://linear.app/supabase/issue/AUTH-1368/scim-users-get-by-id

What is the current behavior?

/scim/v2 serves the three discovery endpoints and nothing else.

Before:

curl -H "Authorization: Bearer $TOKEN" http://localhost:9999/scim/v2/Users/64db64f9-15e5-4da2-a06f-0627c9c76baa | jq
{
  "schemas": [
    "urn:ietf:params:scim:api:messages:2.0:Error"
  ],
  "detail": "A valid SCIM bearer token is required",
  "status": "401"
}

What is the new behavior?

scim.Server.Authenticate resolves the SSO provider that owns the presented bearer token and puts it on the request context. UserByID then returns that provider's user:

case	response
user belongs to the token's provider	200 + User resource, application/scim+json
missing, malformed, or unknown token	401 + WWW-Authenticate: Bearer
token resolves but the provider is disabled	403
unknown id, another provider's user, soft deleted user, malformed id	404, identical body

Discovery stays unauthenticated. Authenticate is scoped to the /Users route so a deployment with no provisioned tenant still serves /Schemas.

After:

モ curl -H "Authorization: Bearer $TOKEN" http://localhost:9999/scim/v2/Users/64db64f9-15e5-4da2-a06f-0627c9c76baa | jq
{
  "schemas": [
    "urn:ietf:params:scim:schemas:core:2.0:User"
  ],
  "id": "64db64f9-15e5-4da2-a06f-0627c9c76baa",
  "userName": "mo@example.com",
  "emails": [
    {
      "value": "mo@example.com",
      "primary": true
    }
  ],
  "meta": {
    "resourceType": "User",
    "created": "2026-08-07T23:34:38.055886Z",
    "lastModified": "2026-08-07T23:34:38.064015Z",
    "location": "https://example.ngrok-free.dev/scim/v2/Users/64db64f9-15e5-4da2-a06f-0627c9c76baa"
  }
}

Additional context

[depthfirst-app]

⚪ Severity: LOW

The server returns HTTP 403 for a valid token whose provider is disabled, versus HTTP 401 for any unknown token. This status-code difference lets an attacker use a disabled SCIM provider as an oracle — submitting candidate tokens and distinguishing valid-but-forbidden ones (403) from invalid ones (401), effectively confirming token validity without gaining access.
Helpful? Add 👍 / 👎

💡 Fix Suggestion

Suggestion: Replace the HTTP 403 response for a disabled provider with the same unauthorized(w) call (HTTP 401) used for unknown tokens. This eliminates the status-code oracle by returning a uniform 401 response whether the token is unrecognised or resolves to a disabled provider, so an attacker can no longer confirm token validity by observing the response code.

⚠️ Experimental Feature: This code suggestion is automatically generated. Please review carefully.

Suggested change

	if !provider.IsEnabled() {
	if !provider.IsEnabled() {
	unauthorized(w)
	return nil, false
	}