LDAP sync fails after changing object_uniqueness_field/ldap_uniq

### Describe the bug

When an LDAP source’s object_uniqueness_field is remapped (e.g., from objectSid to another attribute) and existing ldap_uniq attributes are
migrated, the LDAP sync still tries to create new UserLDAPSourceConnection/GroupLDAPSourceConnection rows keyed by the new
identifier. Existing rows retain the old identifier, so the insert collides with the unique constraint on (user_id, source_id), aborting sync
with a duplicate-key error. Code paths: authentik/sources/ldap/sync/users.py and authentik/sources/ldap/sync/groups.py filter by identifier
only, then insert, rather than update-or-create by (source, user)/(source, group).

### How to reproduce

- Configure an LDAP source with object_uniqueness_field=objectSid (default); sync users/groups.
- Change object_uniqueness_field to a different LDAP attribute (e.g., uidNumber); migrate existing Authentik users’ ldap_uniq attributes to
match the new values.
- Run LDAP sync again.
- Observe sync failure with duplicate key value violates unique constraint "authentik_core_usersourc_user_id_source_id_ad1f5aa7_uniq" (user)
or equivalent for groups.

### Expected behavior

After changing object_uniqueness_field and migrating ldap_uniq, LDAP sync should update the existing source connection’s identifier for that
(user, source)/(group, source) instead of inserting a new row, completing without duplicate-key errors.

### Screenshots

### Additional context

I am getting error log:

```
Failed to create user: duplicate key value violates unique constraint "authentik_core_usersourc_user_id_source_id_ad1f5aa7_uniq"
DETAIL: Key (user_id, source_id)=(20, 7ae0e1c5-325c-41e3-9466-0d33b7282265) already exists. To merge new user with existing user, set the user's Attribute 'ldap_uniq' to 'S-1-5-21-2236801780-3321160328-3458063896-89160'
```

even tho the ldap_uniq is set exactly to the requested value, that can be seen in the attached screenshot

### Deployment Method

Docker

### Version

2025.8.5

### Relevant log output

```shell

```

### Current workaround

• Here’s how to do it via the REST API (no database access needed):

- Ensure you have an API token with rights to read users and update LDAP user connections.
- Use the users endpoint to list all users and note each user’s pk and attributes.ldap_uniq. Build a map: {user_id -> ldap_uniq}. If a user lacks ldap_uniq, skip it.
- Use api/v3/sources/user_connections/ldap/ to list all LDAP user connections. Each item has user (the user id) and identifier.
- For each connection:
- Look up the user in your {user_id -> ldap_uniq} map.
- If there is a ldap_uniq value and it differs from the connection’s identifier, send an update to that connection (PATCH/PUT on its detail URL from the list) setting identifier to the user’s ldap_uniq.
- Repeat for all connections. Once identifiers match the migrated ldap_uniq values, rerun LDAP sync; the duplicate (user, source) constraint error should be resolved.