[Feature] Option to treat accounts as managed by the OAuth provider

[PalmarHealer]

I have searched the existing feature requests, both open and closed, to make sure this is not a duplicate request.

• Yes

The feature

Many instances use OAuth as the only way to log in, with password login disabled. In that setup the identity provider is where users actually manage their account, but Immich's user settings still behave as if accounts were local:

• The Password section is always shown, even though the password there is not the one the user logs in with. Users try to change their password there and are confused when nothing changes at their provider.
• The Unlink OAuth button is always shown. With password login disabled, unlinking leaves the user unable to log in at all (see [Feature] Remove "Unlink Oauth" option when Password Authentication disabled #5112, which this request would cover).
• Since v3.3.0, quota, role and username can be synced from claims on every login, so the provider is already the source of truth for parts of the account. Local edits to these get overwritten on the next login.

Proposal: an admin setting under OAuth, for example "Accounts are managed by the OAuth provider". When it is enabled, for users with a linked OAuth account:

1. The Password section in user settings is replaced by a single "Manage account" / "Change password" action that opens the existing oauthAccountManagementUrl (added in feat: add oauth account management url #30873).
2. The "Unlink OAuth" button is hidden, and the unlink endpoint rejects the request for these users.
3. Optionally, profile fields that are synced from claims are shown as read-only.

The wording shown to users should stay neutral. They should simply be sent to the right place to manage their account, without exposing how the instance is configured. Local, non-OAuth users (for example an emergency admin) are not affected, and admins can still reset or unlink users from the admin panel.

This builds on settings that already exist (passwordLogin.enabled, oauthAccountManagementUrl) and mostly gates existing UI behind one flag.

Platform

• Server
• Web
• Mobile

[bo0tzz]

I think this ultimately boils down to being a duplicate of #5112, which should be broadened to also include hiding the password section.