docs: add Phase 19 user-management CMS wiring plan + product note

PLAN.md

@@ -380,6 +380,64 @@ opacity + muted-text mixes are tune-on-screen details, not decision gates.
 
 ---
 
+## Phase 19 — AuthBlocks User Management in the CMS
+
+Wire the AuthBlocks user-administration surface (create users, manage existing accounts, manage
+registration invites, manage role permissions) into the `DeepDrftManager` CMS so an admin runs account
+management from inside the authenticated CMS. Daniel's framing: *"already part of the AuthBlocks library
+so we just wire it up."* Correct — and **further along than it implies.** Full design, the
+already-done-vs-remaining split, nav-shape alternatives, scope boundaries, and open questions:
+`product-notes/phase-19-user-management-cms.md`.
+
+**Headline finding — most of the wiring already landed by side-effect.** The AuthBlocks startup
+separation (`PLAN_authblocks_trackmanager.md`, 2026-05-25) + the login/logout integration already put
+the entire user-admin surface in place: `Cerebellum.AuthBlocks.Web` is referenced
+(`DeepDrftManager.csproj`), `ConfigureAuthServices` registers every user-admin client + ViewModel
+pointed at DeepDrftAPI (`Program.cs`), the Blazor router already discovers the AuthBlocks pages
+(`Routes.razor` `AdditionalAssemblies`), they already render in `CmsLayout` (`DefaultLayout`), and the
+DeepDrft `Admin` role **inherits** `UserAdmin` (so the seeded admin already passes the page gate with no
+role change). The user-admin pages ship in a published **RCL** (`Cerebellum.AuthBlocks.Web` — an
+`Sdk.Razor` project with no `Program.cs`), so the brief's worried-about "extract pages into an RCL" fork
+**does not arise**. The API host (`api/users/*`, `api/auth/admin-register`, etc.) is already mounted on
+DeepDrftAPI via `MapAuthBlocks`.
+
+**The genuine remaining work is exposure + verification + polish, not integration.** The surface is
+invisible because `CmsLayout` has **no nav menu at all** (just an app bar + Home button), so nothing
+links to `/useradmin/*`. The work: (G1) add navigation; (G2) verify the wired surface end-to-end; (G3) a
+legibility-only theming sweep.
+
+**Sequenced as one real wave + verification.** `19.1 → {19.2, 19.3}`.
+
+- **19.1 — CmsLayout navigation (cold-start, the only code wave).** Add a `MudDrawer` + toggle to
+  `CmsLayout.razor`; mount the shipped `UserAdminMenu` fragment (self-gates to `UserAdmin`+) alongside
+  the existing CMS destinations (Catalogue / Releases / Upload); wire the canonical create-user link
+  (OQ2). **No service, API, data, or AuthBlocks-source change.** **Recommended nav shape: G1-b** (a real
+  drawer reusing AuthBlocks' own `MudNavGroup`) over an app-bar overflow stopgap or a heavier dedicated
+  admin dashboard.
+- **19.2 — End-to-end verification (after 19.1).** Exercise list/create/deactivate users,
+  registrations, permissions against a running DeepDrftAPI; confirm cross-host token + CORS. Mostly
+  test; any break is likely a one-line config fix or an upstream AuthBlocks issue.
+- **19.3 — Theming legibility sweep (after 19.1, parallel-ok).** Accept the CMS palette for the
+  MudBlazor-default grids; fix only contrast/legibility breaks. Bespoke restyle deferred.
+
+**Deferred (note, don't build):** an admin dashboard landing (G1-c); working **Reset Password** (the
+AuthBlocks Users page stubs it — an *upstream AuthBlocks-repo* effort, not a DeepDrft wiring task);
+bespoke restyle of the AuthBlocks grids; surfacing self-service registration on the public site;
+bumping `Cerebellum.AuthBlocks.Web` 10.3.33 → 10.3.35 (housekeeping, Daniel's timing).
+
+**Open questions for Daniel (spec §6):** (1) nav shape — confirm **G1-b**; (2) canonical create-user
+entry — `SuperRegister` (role multiselect, recommended) vs. `NewUser` (bare form); (3) admin dashboard
+defer vs. include (recommend defer); (4) package bump now vs. separate (recommend leave); (5) confirm
+Reset Password is accepted **non-functional in v1** so verification doesn't file it as a DeepDrft bug.
+Items 1, 2, 5 shape the work/acceptance; 3, 4 don't block 19.1.
+
+**Adjacency to the deferred Identity / accounts backlog item (below).** That item is about *public,
+per-user* identity (favourites, listening history, playlists). This phase is *CMS-admin* account
+management only — same AuthBlocks substrate, different surface. They are not the same work; this phase
+does not satisfy or depend on that one.
+
+---
+
 ## Working with this file
 
 - **Add items by extending an existing phase first**; only create a new phase when the addition genuinely doesn't fit any of 1–5. Phase numbers are organisational, not sequencing.