docs(19.6.1-04): state Administrators outranking on the D-14 seam

- cabana, not the contributor, applies guardOutranked before a contributed Run
- A contribution to summercms.cabana.users is 403 user.outranked when the target outranks the caller

Co-authored-by: Cursor <cursoragent@cursor.com>

docs/backend/admin-controllers.md

@@ -525,6 +525,7 @@ The admin merges the contributions at boot, after the target's own record action
 
 - It is offered on the target's preview screen, after the owner's actions, while its `Applies` reports true, and it runs through the same `POST /{controller}/{id}/actions/{action}` route: the record is loaded through the target's `pact.FormExtendQuery` scope with a row lock, and `Run` receives it in `pact.AdminRecordActionInput`.
 - Both the target controller's `RequiredPermissions` and the action's own `Permissions` apply, so an action on the Administrators screen needs `backend.manage_users` and its own code. Its `Permissions` must name codes some activated plugin registers.
+- A contribution to `summercms.cabana.users` / `cabana.AdministratorsControllerID` is also refused with 403 `user.outranked` when the target administrator's effective grants are not a subset of the caller's. cabana applies this before `Run`, so the contributor does not.
 - A record action carries no input beyond the record.
 
 The start-up stops on an unknown controller ID, a target whose `config_form.yaml` has no `preview` block (record actions are offered on the preview screen), a name the target already registers (its owner's, or an earlier contribution's), a reserved name (`create`, `delete`), a name that is not an identifier, an action without `Run`, or an empty label. Prefix contributed names with your plugin (`acme_...`) so they cannot collide with names the owner adds later.