Treat member order as insignificant when resolving a group

"jane+john" and "john+jane" name the same group, but they did not behave
that way. Jellyfin only routes a login here when no account matches the
typed name, so logging in with the reversed spelling of an existing group
found nothing and quietly created a second shared account for the same
two people - each with its own watched state.

Group identity is now order-independent:

- Member names are sorted alphabetically when building an account name,
  so a given set of members always produces the same name.
- Before creating anything, the login path looks for an existing group
  whose members are exactly the named set, compared as a set rather than
  a sequence, and logs into that account if it finds one.
- Stored member lists are kept in the same canonical order on create and
  update, so a group's stored order does not depend on the order an
  admin happened to select members in.

Passing no name through to provisioning lets it generate the canonical
name, rather than preserving whatever order was typed.

Members are also now checked in the order they were typed, stopping at
the first match, so whoever puts their own name first is verified first.
Verification is a deliberately slow hash comparison, so the ordering is
worth having; it is only a preference, and any member's password still
unlocks the group.

Jellyfin.Plugin.WatchedTogether/Services/DynamicGroupService.cs

@@ -116,7 +116,12 @@ public class DynamicGroupService : IDynamicGroupService
 
         // The password must belong to one of the named members. Without this any visitor could
         // conjure a shared account out of two usernames they happened to know.
-        if (!members.Any(m => VerifyPassword(m, password)))
+        //
+        // Members are tried in the order they were typed and the loop stops at the first match, so
+        // whoever types their own name first has their password checked first. Verification is a
+        // deliberately slow hash comparison, so the ordering is worth having.
+        var matched = members.FirstOrDefault(m => VerifyPassword(m, password));
+        if (matched is null)
         {
             _logger.LogWarning(
                 "Dynamic group login for {Username} rejected: no named member's password matched",
@@ -124,11 +129,45 @@ public class DynamicGroupService : IDynamicGroupService
             return null;
         }
 
+        var memberIds = members.Select(m => m.Id).ToList();
+
+        // The same people in a different order are the same group: someone typing "john+jane" must
+        // land on the existing "jane+john" account rather than creating a second one. Jellyfin only
+        // reaches this code when no account matches the typed name, so without this check every
+        // ordering would spawn its own account.
+        var existing = FindGroupWithSameMembers(config, memberIds);
+        if (existing is not null)
+        {
+            if (existing.IsDisabled)
+            {
+                _logger.LogWarning(
+                    "Login for {Username} rejected: the matching group is disabled",
+                    enteredUsername);
+                return null;
+            }
+
+            var existingUser = _userManager.GetUserById(existing.SharedUserId);
+            if (existingUser is null)
+            {
+                _logger.LogWarning(
+                    "Group for {Username} references a shared account that no longer exists",
+                    enteredUsername);
+                return null;
+            }
+
+            _logger.LogInformation(
+                "Login as {Entered} resolved to the existing shared account {Username}",
+                enteredUsername,
+                existingUser.Username);
+
+            return new DynamicGroupResult(existing, existingUser.Username);
+        }
+
+        // Passing no name lets provisioning generate the canonical alphabetically-sorted one, so
+        // the account is named the same whichever order the members were typed in.
         // The account is limited to the libraries all named members share, so creating one at the
         // login screen cannot grant anybody access they did not already have.
-        var group = await _provisioningService.CreateGroupAsync(
-            members.Select(m => m.Id).ToList(),
-            enteredUsername).ConfigureAwait(false);
+        var group = await _provisioningService.CreateGroupAsync(memberIds, null).ConfigureAwait(false);
 
         var sharedUser = _userManager.GetUserById(group.SharedUserId);
         if (sharedUser is null)
@@ -144,6 +183,22 @@ public class DynamicGroupService : IDynamicGroupService
         return new DynamicGroupResult(group, sharedUser.Username);
     }
 
+    /// <summary>
+    /// Finds a configured group whose members are exactly the given set, ignoring order.
+    /// </summary>
+    /// <param name="config">The plugin configuration to search.</param>
+    /// <param name="memberIds">The member identifiers to match.</param>
+    /// <returns>The matching group, or <c>null</c> if no group has that membership.</returns>
+    private static SharedGroup? FindGroupWithSameMembers(
+        PluginConfiguration config,
+        IReadOnlyList<Guid> memberIds)
+    {
+        var wanted = memberIds.ToHashSet();
+
+        return config.Groups.FirstOrDefault(g =>
+            g.MemberUserIds.Count == wanted.Count && wanted.SetEquals(g.MemberUserIds));
+    }
+
     /// <summary>
     /// Verifies a submitted password against a member's live stored hash.
     /// </summary>