LDAP bind fails with Insufficient access (50) when provider is used as backchannel for an unrelated application (regression in 2026.8.0)

### Describe the bug

An LDAP bind service account that is only granted the "Search full LDAP directory" permission and is included in the user bindings of its primary LDAP Application starts failing to bind with `ldap_bind: Insufficient access (50)` after upgrading to 2026.8.0, if the same LDAP Provider is also referenced as a **backchannel provider** by a second, unrelated OAuth2 Provider Application — and the bind account is *not* part of that second application's user bindings.

The service account (`ldapservice`) and role setup were created by following the ["Create an LDAP provider"](https://docs.goauthentik.io/add-secure-apps/providers/ldap/create-ldap-provider/) documentation exactly, including the recommended naming (`ldapservice`) and the dedicated Role with the "Search full LDAP directory" object permission on the Provider.

This setup worked without issue up to and including 2026.5.6. The bind account was never intended to have any access to the second (OAuth2) application; it only needs to search the LDAP directory via the LDAP Provider/Application it is actually bound to.

Adding the bind account to the user bindings of the second, unrelated application resolves the issue, but this shouldn't be necessary since:
1. The bind account has no direct relationship to that application at all.
2. The LDAP Provider is used purely as a backchannel provider there, not as the application's primary authentication method.
3. This effectively forces granting the bind account access to every application that happens to reference the LDAP Provider in any capacity, which conflicts with the principle of least privilege.

There is also a legitimate architectural reason to have a single LDAP Provider serve both a stand-alone LDAP Application and act as backchannel provider for an OAuth2 Application: a self-hosted mail stack where Dovecot authenticates IMAP/SMTP logins directly against the LDAP Provider (LDAP Application), while Roundcube authenticates the same users via OAuth2/OIDC against an Authentik OAuth2 Provider that in turn uses that same LDAP Provider as its backchannel for the IMAP login step. Both access paths need to resolve against the same directory, but only the LDAP-side bind account should need "Search full LDAP directory" — it has no reason to be a user binding on the OAuth2/Roundcube application.

This appears related to #9245, which describes a similar cross-application binding requirement when a single LDAP outpost serves multiple LDAP-type applications. This report additionally reproduces the issue when the second application is **not** an LDAP application, but an OAuth2 application using the LDAP provider only as a backchannel provider.

### How to reproduce

Steps to reproduce the behavior:
1. Create an LDAP Provider and an LDAP Application, and bind them together (per the documentation linked above).
2. Create a Role (e.g. "LDAP search"), add a service account (e.g. `ldapservice`) to it, and assign the Role the "Search full LDAP directory" object permission on the LDAP Provider.
3. Add the service account to the LDAP Application's user bindings.
4. Deploy an LDAP Outpost serving this LDAP Application.
5. Confirm `ldapsearch` binds and searches successfully as `ldapservice`.
6. Create a second, unrelated OAuth2 Provider and Application. Configure the same LDAP Provider as its **backchannel provider**.
7. Do **not** add `ldapservice` to the second application's user bindings.
8. Attempt the same `ldapsearch` bind as `ldapservice` again.

### Expected behavior

The bind should continue to succeed, since `ldapservice` has the "Search full LDAP directory" permission on the LDAP Provider and is bound to the LDAP Application it is actually meant to use. Being a backchannel provider for an unrelated OAuth2 application should not affect access checks for LDAP binds.

### Screenshots

_No response_

### Additional context

This looks like a regression introduced between 2026.5.6 and 2026.8.0, possibly related to changes in how application/provider access bindings are evaluated for LDAP outposts serving multiple providers, or how backchannel provider relationships are factored into those checks. Worth checking whether backchannel providers were previously excluded from this evaluation and are now incorrectly included.

### Deployment Method

Docker

### Version

2026.8.0

### Relevant log output

```shell

```

Start by reproducing the LDAP outpost bind with the shared LDAP Provider, first without and then with the unrelated OAuth2 application's backchannel reference. Trace the application/provider access-binding evaluation for LDAP binds and compare behavior between 2026.5.6 and 2026.8.0. Done means the bind account can use its bound LDAP Application without being added to unrelated application's user bindings.

Written by the indexing model from the issue text.