feat(19.3-04): pact.ReorderAfterSave hook inside cabana's reorder transaction

- optional ReorderAfterSave(ctx, partition) runs after the new order is
  written; an error rolls the reorder back through lifecycleFailure
- reorderPost runs in lagoon.Transaction so lagoon.AfterCommit work a hook
  registers (a site-cache purge) runs only after the commit
- pact and cabana READMEs, admin hook table, tree reorder docs

docs/backend/admin-controllers.md

@@ -215,6 +215,7 @@ Behaviour overrides such as `formBeforeCreate` or `listExtendQuery` become optio
 | `pact.FormBeforeCreate`, `pact.FormAfterCreate` | Around a create, inside its transaction. |
 | `pact.FormBeforeUpdate`, `pact.FormAfterUpdate` | Around an update, inside its transaction. |
 | `pact.FormBeforeDelete`, `pact.FormAfterDelete` | Around a delete, inside its transaction. |
+| `pact.ReorderAfterSave` | After a reorder save wrote the new order, inside its transaction, with the request's partition (nil without one). An error rolls the reorder back. See [Tree reorder](lists-and-filters.md#tree-reorder). |
 | `pact.DropdownOptionsProvider` | Supplies the options of a `dropdown` field that names a method. |
 
 A hook or scope that has to read the database during a write should use the transaction the write runs in, `cabana.TxFromContext(ctx)`, rather than the application pool: it then sees the write's own snapshot and takes no second connection while the transaction holds row locks. The handle is valid only until the hook returns, and the list route, which runs no transaction, reports none.