Blueprint apply is racy under concurrent or first-start runs

## What

blueprint apply is racy/flaky: concurrent apply, duplicate “Apply single Blueprint” tasks, and first-start random error-then-success.

## Want

- Blueprint apply is racy/flaky: concurrent apply, duplicate “Apply single Blueprint” tasks,
- First-start random error-then-success

## Ideas this came from

- [#19715 Blueprint race condition: concurrent apply causes !Find to resolve to None](https://github.com/goauthentik/authentik/issues/19715) — Context We run Authentik as our SSO provider across multiple Kubernetes clusters. To manage configuration declaratively, we store blueprints in ConfigMaps and m
- [#22193 Authentik randomly schedules multiple "Apply single Blueprint" tasks for the same blueprint](https://github.com/goauthentik/authentik/issues/22193) — I've noticed recently when creating multiple new blueprint configmaps at the same time, Authentik will schedule the "Apply single Blueprint" task multiple times
- [#22439 On first startup, blueprint randomly has status error then, sometimes after, successful](https://github.com/goauthentik/authentik/issues/22439) — I'm developing a website with OIDC authentication using Authentik. I run authentik locally through docker and set up my configuration using a blueprint. Very of

No file or test is named. Start by reproducing concurrent blueprint applies, duplicate "Apply single Blueprint" tasks, and the first-start error-then-success behavior; trace the blueprint apply workflow and its task scheduling. Done means these scenarios no longer produce flaky errors or duplicate work.

Written by the indexing model from the issue text.