docs(2.58): correct the migration story — 0266/0267/0268 ship in 2.58, not 2.57

Prior wording incorrectly claimed dojo.0267_backfill_authorized_users
shipped in 2.57. None of the three new migrations (0266 reintroduce
authorized_users M2M, 0267 backfill, 0268 release RBAC state) are in
2.57.x or master — they are introduced in this 2.58 cycle and run
automatically on upgrade. The preview_legacy_authorization_migration
management command also ships in 2.58, so the audit-before-upgrade
recommendation has to run against a staging install of 2.58 with a
prod DB snapshot, not against 2.57.

Author: devGregA

docs/content/releases/os_upgrading/2.58.md

@@ -22,8 +22,8 @@ Both endpoints are gated so only `is_staff` / `is_superuser` users can add or re
 
 ### Required actions
 
-- **No data migration required.** Migration `dojo.0267_backfill_authorized_users` (shipped in 2.57) already populated `authorized_users` from the prior RBAC tables, so existing access is preserved.
-- **Audit the migration before you upgrade** with `python manage.py preview_legacy_authorization_migration` (add `--json` for machine-readable output). It is read-only and reports the `authorized_users` pairs that would be created per Product / Product Type (broken down by direct member vs flattened group member), the `is_superuser` / `is_staff` flag flips driven by `Global_Role(Owner)` / `Global_Role(Maintainer | API_Importer)`, and the role-granularity (Reader / Writer / Maintainer per-product) and group-based authorization that the legacy model cannot preserve. Run it on a snapshot of production before the upgrade so you know exactly what will and will not survive.
+- **Three new migrations run automatically on upgrade.** `dojo.0266_reintroduce_authorized_users` schema-creates the `Product.authorized_users` / `Product_Type.authorized_users` M2M tables. `dojo.0267_backfill_authorized_users` walks the prior `Product_Member` / `Product_Type_Member` / `Product_Group` / `Product_Type_Group` / `Dojo_Group_Member` rows and inserts the corresponding `authorized_users` pairs (group-based memberships are flattened to user pairs), then flips `is_superuser=True` for users with `Global_Role(Owner)` and `is_staff=True` for users with `Global_Role(Maintainer | API_Importer)`. `dojo.0268_release_rbac_state` flips the RBAC models to `managed=False` in dojo's state so a Pro install can later adopt the existing tables. Migration `0267` is idempotent and a no-op on a fresh OS install (the `dojo_role` introspection guard short-circuits when no RBAC data exists).
+- **Audit the migration before you upgrade** with the new `python manage.py preview_legacy_authorization_migration` command (add `--json` for machine-readable output). It is read-only and reports the `authorized_users` pairs that would be created per Product / Product Type (broken down by direct member vs flattened group member), the `is_superuser` / `is_staff` flag flips, and the role-granularity (Reader / Writer / Maintainer per-product) and group-based authorization that the legacy model cannot preserve. The command itself ships in 2.58 — run it against a staging snapshot of your prod DB *after* installing 2.58 there, then audit the output, then upgrade prod. Idempotent on already-migrated DBs (reports zero pending changes).
 - **If you later install Pro on top of an OS deployment**, run `python manage.py reconcile_authorized_users_to_rbac --dry-run` and then re-run without `--dry-run` to apply. It walks `Product.authorized_users` / `Product_Type.authorized_users` and creates the matching `Product_Member` / `Product_Type_Member` rows under a configurable role (`--role Writer` by default), so any `authorized_users` edits you made while running OS-only flow back into Pro RBAC. Idempotent — re-running after a successful apply prints "Already reconciled".
 
 ### Pro customers are not impacted