feat(scim): Add SCIM /Users endpoints

[xlgmokha]

What kind of change does this PR introduce?

Feature. Add SCIM endpoints for core User schema.

What is the current behavior?

These endpoints do not exist yet.

What is the new behavior?

Adds:

Method	Path	Description
GET	/scim/v2/Users	List / paginate / sort SCIM users
GET	/scim/v2/Users/{id}	Get a specific SCIM user
POST	/scim/v2/Users	Create a new SCIM user
PUT	/scim/v2/Users/{id}	Replace a specific SCIM user
DELETE	/scim/v2/Users/{id}	Delete (soft) a specific SCIM user
GET	/scim/v2/ResourceTypes/{id}	Resource Type endpoint for User resource
GET	/scim/v2/Schemas/{id}	Schema description endpoint for User schema

Additional context

• The /Users endpoints authenticate with a bearer SCIM token. Tokens are stored hashed in the new scim_tokens table, are revocable (revoked_at) and expirable (expires_at), and resolve to an sso_provider_id that scopes every query to a single tenant.
• The new /ResourceTypes/{id} and /Schemas/{id} routes are discovery metadata and are unauthenticated, consistent with the existing /ServiceProviderConfig, /ResourceTypes, and /Schemas endpoints.
• All SCIM routes stay behind the existing requireScimServerEnabled gate.
• New migrations add the scim_users and scim_tokens tables. A user's SCIM payload is stored as a JSONB resource column and deletes are soft using deleted_at.
• PATCH and filtering are not implemented yet. List rejects any filter parameter.

Extracted from #2731

[annabkr]

question: could we break this up for easier review? I find Claude is pretty good at doing that, if it feels tedious to do yourself

[hf]

Looks good, some minor clarifications not blocking from my POV.

[hf]

Shouldn't all of these have omitempty?

[xlgmokha]

Shouldn't all of these have omitempty?

RFC 7643 says:

Unlike other core resources, the "Schema" resource MAY contain a complex object within a sub-attribute, and all attributes are REQUIRED unless otherwise specified.

So I opted to not add the omitempty so that they get the default zero values which would be false for all booleans.

field	required
name	Y
name	Y
type	Y
multiValued	Y
description	Y
required	Y
caseExact	Y
mutability	Y
returned	Y
uniqueness	Y
canonicalValues	N
referenceTypes	N
subAttributes	N

[hf]

How is ?sortBy (without =true) handled here?

[xlgmokha]

How is ?sortBy (without =true) handled here?

I think this will return as a default sort order and then the default sorting will kick in. I'll double check though.