feat: Enhance user group management and transaction handling in stored procedures

- Improved user group deletion logic to accurately report success or failure.
- Updated user group renaming checks to prevent unintended inserts or updates.
- Added documentation on transaction blocking risks during full resets in stored procedures.
- Removed unnecessary login scripts from database project.

Fuchs_Database/dbo/Stored Procedures/fis_admin_delUserGroup.sql

@@ -13,6 +13,11 @@ BEGIN
 	SET NOCOUNT ON;
 	DECLARE @utcnow datetime = GETUTCDATE();
 	DECLARE @auth smallint = [dbo].[fis_admin_getUserAuth](@authaccount);
+	-- Tracks whether THIS call actually soft-deleted an active group, so a never-existing or
+	-- already-deleted @usergroup_id reports failure instead of a false "ok:true" (the previous
+	-- version derived success from "not currently active", which is also true when nothing here
+	-- ever existed).
+	DECLARE @deleted bit = 0;
 
     IF @auth > 1 AND EXISTS (SELECT * FROM [dbo].[fis_usergroups] WHERE [usergroup_id] = @usergroup_id and [DateDeleted] is null)
 		BEGIN
@@ -21,10 +26,22 @@ BEGIN
 				SET [UserDeleted] = @authaccount
 				   ,[DateDeleted] = @utcnow
 			 WHERE
-				  [usergroup_id] = @usergroup_id;
+				  [usergroup_id] = @usergroup_id
+				  AND [DateDeleted] is null;
+
+			IF @@ROWCOUNT > 0 SET @deleted = 1;
+
+			-- Soft-delete the group's active memberships too, matching the confirm text
+			-- ("Die Mitgliedschaft aller Benutzer in dieser Gruppe geht dabei verloren.").
+			UPDATE [dbo].[fis_usergroups_members]
+				SET [UserDeleted] = @authaccount
+				   ,[DateDeleted] = @utcnow
+			 WHERE
+				  [usergroup_id] = @usergroup_id
+				  AND [DateDeleted] is null;
 
 		END
 
-	SELECT CAST((CASE WHEN NOT EXISTS (SELECT * FROM [dbo].[fis_usergroups] WHERE [usergroup_id] = @usergroup_id and [DateDeleted] is null) THEN 1 ELSE 0 END) as bit);
+	SELECT @deleted;
 
 END

Fuchs_Database/dbo/Stored Procedures/fis_admin_setUserGroup.sql

@@ -17,9 +17,14 @@ BEGIN
 
 	DECLARE @createdID as TABLE ([id] varchar(5));
 
-	IF @auth > 1
+	-- Renaming an existing group (@usergroup_id supplied) requires that id to currently be an
+	-- active group; otherwise the MERGE below would silently INSERT it as a brand-new group
+	-- (rename-of-unknown-id becoming create) or resurrect/UPDATE a soft-deleted row without
+	-- clearing its DateDeleted (leaving it deleted yet renamed). @usergroup_id = NULL (create)
+	-- always passes this check.
+	IF @auth > 1 AND (@usergroup_id IS NULL OR EXISTS (SELECT * FROM [dbo].[fis_usergroups] WHERE [usergroup_id] = @usergroup_id AND [DateDeleted] IS NULL))
 	BEGIN
-		
+
 			MERGE [dbo].[fis_usergroups] as TARGET
 				USING (VALUES(	ISNULL(@usergroup_id, [dbo].[fis_fn_id] ('fis_usergroups'))
 								,ENCRYPTBYKEY(@enc_key, @name)

Fuchs_Database/dbo/Stored Procedures/mfr__updt__companies.sql

@@ -20,6 +20,11 @@ BEGIN
 	DECLARE @tmp_cmd nvarchar(1000) = N'SELECT DISTINCT * FROM ' + @tblname
 	INSERT INTO @tmp EXECUTE [sp_executesql] @tmp_cmd;
 
+	-- Wrapping the DELETEs + MERGE below in one transaction gives all-or-nothing atomicity for
+	-- this entity's sync batch (same pattern in every mfr__updt__* proc). During a large full
+	-- reset this can hold locks on the affected tables for as long as the batch takes to run —
+	-- an accepted, documented risk, not an oversight. See
+	-- Docs/Decisions/0022-mfr-sync-transaction-blocking-accepted-risk.md before changing this.
 	BEGIN TRANSACTION;
 
 	IF @referencetable = 'mfr__companies'