Upgrade 2026.5.7 → 2026.8.2 fails: InconsistentMigrationHistory — authentik_core.0064_..._idx applied before its 2026.8 dependency authentik_core.0063_actor / authentik_rbac.0011

### Describe the bug

Upgrading from **2026.5.7** to **2026.8.2** (docker compose) puts the `server`
container into a permanent crash loop. Django's migration **consistency check**
fails before any migration is applied:

```
django.db.migrations.exceptions.InconsistentMigrationHistory:
Migration authentik_core.0064_user_authentik_c_usernam_2f0e4b_idx is applied
before its dependency authentik_core.0063_actor on database 'default'.
```

(also seen against `authentik_rbac.0011_initialpermissionspermission`.)

The Rust server wrapper then reports the backend gone and the container restarts,
looping indefinitely (`RestartCount` climbed to 16 in ~1 minute):

```
{"filename":"src/server/mod.rs","level":"warn",...,"code":"ExitStatus(unix_wait_status(256))","event":"server has exited"}
{"filename":"src/main.rs","level":"error",...,"event":"authentik encountered errors"} the server has exited unexpectedly
```

### Root cause (analysis)

The 2026.5 and 2026.8 migration branches appear to have diverged:

- `authentik_core.0064_user_authentik_c_usernam_2f0e4b_idx` shipped in the
**2026.5** line and is applied in our DB (applied during the 2026.5.7 upgrade).
- `authentik_core.0063_actor` and `authentik_rbac.0011_initialpermissionspermission`
are **2026.8-only** migrations, **not** present in the 2026.5 graph, so they are
not applied in a DB coming from 2026.5.x.
- In 2026.8, `0064_..._idx` **depends on** `0063_actor` — a migration numbered
*lower* than one already applied from the 2026.5 branch. Django's
`check_consistent_history` therefore fails ("0064 applied before its
dependency 0063").

i.e. a released 2026.5 migration effectively gains a back-dependency on a
newly-inserted, lower-numbered 2026.8 migration. `--fake`-applying `0063_actor`
is not a safe workaround because it is a real schema change (creates the actor
table).

Migration history from the affected DB:

```
app | name | applied
----------------+------------------------------------------+---------------------------
authentik_rbac | 0010_remove_role_group_alter_role_name | 2026-03-14 12:28:25+00
authentik_core | 0064_user_authentik_c_usernam_2f0e4b_idx | 2026-09-10 00:20:07+00 (from 2026.5.7)
(authentik_core.0063_actor and authentik_rbac.0011 are NOT applied — 2026.8-only)
```

### To reproduce

1. Run **2026.5.7** (a DB that has `authentik_core.0064_..._idx` applied but not `0063_actor`).
2. Upgrade to **2026.8.2** (bump image tags, `docker compose pull && up -d`).
3. `server` crash-loops on the `InconsistentMigrationHistory` above.

### Expected behavior

The 2026.5.7 → 2026.8.2 upgrade migrates cleanly. The 2026.8 migration graph
should not make an already-released 2026.5 migration depend on a newly-inserted,
lower-numbered migration (a merge migration or corrected dependency is likely
needed).

### Version and Deployment

- authentik **2026.5.7 → 2026.8.2** (fails)
- Deployment: **docker-compose**
- PostgreSQL **16-alpine**; Python **3.14** (per traceback path)
- Upgrade history reaching 2026.5.7: 2025.10.2 → 2025.10.4 → 2025.12.4 →
2026.2.1 → 2026.2.2 → 2026.2.3 → 2026.2.4 → 2026.2.6 → 2026.5.6 → 2026.5.7

### Workaround used

Reverted the image tag to 2026.5.7 and restarted. Because the failure is in the
migration **planning/consistency** phase (before anything is applied), the DB is
untouched and 2026.5.7 comes back cleanly with no DB restore needed.