SCIM: Okta on-prem agent setup fails

Nobody has claimed this yet.

### Describe the bug

Metabase SCIM 2.0 only implements /Users and /Groups. Metabase docs say Okta is supported and links to the generic Okta setup documentation so it's a natural assumption that the on prem provisioning agent would work as well.

OPP’s connector test GETs {base}/ServiceProviderConfig. That path doesn’t exist. The request 401s (SCIM auth wraps all of /v2), so it looks like a bad token. POST /Users with the same token works.

### To Reproduce

OPP’s connector test GETs {ase}/ServiceProviderConfig (which fails, of course, because it doesnt exist):

https://help.okta.com/en-us/content/topics/provisioning/opp/opp-provision-scim-messages.htm

### Expected behavior

Connector setup against a documented supported IdP should succeed (GET '/api/ee/scim/v2/ServiceProviderConfig' should return a SCIM discovery document for the capabilities Metabase supports)

Until that exists, we should probably update docs to indicate that we support Okta cloud SCIM, specifically, but not the on-prem agent.

### Logs

_No response_

### Information about your Metabase installation

```JSON
v63 (not new behavior - looks like this was never implemented)
```

### Severity

prevents SCIM setup for Okta on-prem agent users

### Additional context

A possible workaround it to stub that GET on a reverse proxy

Start by locating the SCIM 2.0 /api/ee/scim/v2 routes and checking how GET /ServiceProviderConfig is handled, alongside the existing /Users and /Groups behavior. Compare the endpoint requirements with Okta’s connector test. Done means the documented Okta on-prem setup succeeds with a SCIM discovery response, or the documentation clearly limits support to Okta cloud.

Written by the indexing model from the issue text.