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/ProvisioningService.cs

@@ -88,6 +88,12 @@ public class ProvisioningService : IProvisioningService
             members.Add(member);
         }
 
+        // Store members in the same alphabetical order the generated name uses, so that the stored
+        // order is canonical however the members were supplied. Password checks then always run in
+        // a predictable order too.
+        members = members.OrderBy(m => m.Username, StringComparer.OrdinalIgnoreCase).ToList();
+        distinctIds = members.Select(m => m.Id).ToList();
+
         var accountName = string.IsNullOrWhiteSpace(name)
             ? BuildDefaultName(members.Select(m => m.Username), config.NameSeparator)
             : name.Trim();
@@ -165,6 +171,11 @@ public class ProvisioningService : IProvisioningService
             }
         }
 
+        // Keep the stored order canonical, matching how groups are created.
+        distinctIds = distinctIds
+            .OrderBy(id => _userManager.GetUserById(id)?.Username, StringComparer.OrdinalIgnoreCase)
+            .ToList();
+
         group.MemberUserIds = distinctIds;
         group.SyncUnwatched = syncUnwatched;
         group.SyncPlayCount = syncPlayCount;
@@ -211,15 +222,20 @@ public class ProvisioningService : IProvisioningService
 
     /// <summary>
     /// Joins member names into a display name, falling back to a generic name if the result would
-    /// exceed the username column limit. Membership is tracked by GUID, so the name is cosmetic.
+    /// exceed the username column limit.
     /// </summary>
+    /// <remarks>
+    /// Names are sorted alphabetically so that a given set of members always produces the same
+    /// account name. Without this, "jane+john" and "john+jane" would be two different names for the
+    /// same group and would end up as two separate accounts.
+    /// </remarks>
     /// <param name="usernames">The member usernames.</param>
     /// <param name="separator">The configured separator.</param>
     /// <returns>A name that fits within the username length limit.</returns>
     private static string BuildDefaultName(IEnumerable<string> usernames, string separator)
     {
         var sep = string.IsNullOrEmpty(separator) ? "+" : separator;
-        var joined = string.Join(sep, usernames);
+        var joined = string.Join(sep, usernames.OrderBy(n => n, StringComparer.OrdinalIgnoreCase));
 
         if (joined.Length <= MaxUsernameLength)
         {