Support profile attribute mapping from validated ID tokens for AD FS (Pro OIDC)

### Self Checks

- [x] I have read the [Contributing Guide](https://docs.cloudreve.org/api/contributing) and [Language Policy](https://github.com/cloudreve/cloudreve/discussions/3335).
- [x] I have searched for existing issues [search for existing issues](https://github.com/cloudreve/cloudreve/issues), including closed ones.
- [x] I confirm that I am using English to submit this report, otherwise it will be closed. / 请使用英语提交，否则会被关闭。
- [x] Please do not modify this template :) and fill in all the required fields.

### 1. Is this request related to a challenge you're experiencing? Tell me about your story.

We are integrating Cloudreve Pro v4 (Docker Compose deployment) with AD FS on Windows Server 2019 (1809) for an organization with several hundred users.

OIDC sign-in succeeds with the requested scopes `openid profile email`, but Cloudreve displays a UUID-like name and an address ending in `@openid.unmanaged` instead of the user's name and email.

We inspected the actual UserInfo response during a successful Cloudreve sign-in. It returned HTTP 200, `application/json;charset=UTF-8`, and exactly one nonempty string field:

```json
{
"sub": ""
}
```

There were no `name`, `email`, `upn`, or `unique_name` fields. TLS trust was verified. The temporary diagnostic forwarded the response unchanged, recorded only field names/types/presence, and was removed after the test.

The current UserInfo field mapping cannot retrieve attributes that are absent from this response. Microsoft explicitly documents that AD FS does not support additional claims through its built-in UserInfo endpoint and points applications to customized ID tokens instead.

Could Cloudreve Pro support mapping user profile attributes such as `name` and `email` from a validated ID token, optionally as a fallback when those fields are absent from UserInfo? This would let organizations retain AD FS without deploying a separate identity broker solely to provide profile attributes.

If this is already supported, please point us to the relevant configuration and minimum version. Otherwise, please consider this a feature request. We have not yet verified the profile claims in our own ID token; configuring AD FS to issue those claims would be the next step if Cloudreve can consume them.

### 2. Additional context or comments

- [Cloudreve OIDC documentation](https://docs.cloudreve.org/en/usage/oidc) describes profile mapping from UserInfo.
- [Microsoft AD FS FAQ](https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/overview/ad-fs-faq#operations), under "I'm trying to get more claims on the UserInfo endpoint, but it's only returning subject. How can I get more claims?", documents this limitation.
- #2838 concerns field mapping within a UserInfo response.
- #2993 describes a similar placeholder email with Microsoft Entra ID. This request concerns AD FS's documented UserInfo limitation and an additional profile source.
- #3472 concerns Cloudreve acting as an OIDC provider; this request concerns Cloudreve consuming an external provider's ID token.

The proposed option should use only verified ID-token claims, retain stable account identifiers, and enforce subject consistency when combining ID-token and UserInfo data. Existing UserInfo-based behavior could remain the default.

An identity broker such as Keycloak is an alternative, but it adds another service to operate. This request is specifically for native ID-token profile mapping. No credentials, tokens, internal hostnames, or real user identifiers are included here.

### 3. Can you help us with this feature?

- [x] I am interested in contributing to this feature.

Start with the OIDC documentation linked in the issue and inspect the existing UserInfo profile-mapping entry point. Verify how validated ID-token claims and UserInfo subjects are currently handled, then define tests for the fallback, subject consistency, and preservation of existing behavior; done means AD FS profile claims can be mapped safely from the ID token.

Written by the indexing model from the issue text.