fix(datatables): the three transactions that still locked before the settings row

Offboarding reassigns a departing user's scripts, flows, apps and resources —
rows a rename writes while holding the settings row — so it takes that row
first, and offboarding from several workspaces walks them in `workspace_id`
order. Removing a member locked the `usr` row before the removal reached the
settings row, and a rename renamed the `password` row before its first
workspace: both now come after.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01S5arH3G2Sa1Qqm32veJQ1n

backend/windmill-api-users/src/users.rs

@@ -2585,6 +2585,11 @@ async fn delete_workspace_user(
 ) -> Result<String> {
     let mut tx = db.begin().await?;
 
+    // Before the `usr` row below — see `lock_workspace_settings_unchecked`. The
+    // removal itself takes this row too; re-acquiring it inside a transaction
+    // costs nothing.
+    windmill_common::workspaces::lock_workspace_settings_unchecked(&mut tx, &w_id).await?;
+
     // Locked so that the authorization below and the delete it guards see the same row.
     let target = sqlx::query!(
         "SELECT email, is_admin FROM usr where username = $1 AND workspace_id = $2 FOR UPDATE",