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.

README.md

@@ -81,13 +81,23 @@ On an unrecognised name, it:
 
 1. Splits the name on the separator (`+` by default) — `alice+bob+carol` → three parts.
 2. Requires **every part** to be an existing, enabled user that is not itself a shared account.
-3. Requires the submitted password to match **one of those members'** stored hashes.
-4. Only then creates the shared account, and returns its name so Jellyfin completes the login.
+3. Requires the submitted password to match **one of those members'** stored hashes. Members are
+   checked in the order you typed them and the check stops at the first match, so putting your own
+   name first is marginally quicker.
+4. Looks for an existing group with exactly those members. If one exists, you are logged into it.
+5. Otherwise creates the shared account, and returns its name so Jellyfin completes the login.
 
 Step 3 is what stops this being an open door: knowing two usernames is not enough to bring an
 account into being. If any check fails, the plugin declines and the login fails exactly as an
 ordinary typo would.
 
+#### Order does not matter
+
+`john+jane` and `jane+john` are the same group. Member names are sorted alphabetically to build the
+account name, and the lookup in step 4 compares members as a set, so both spellings resolve to one
+account rather than creating a second one for the same two people. The account itself is named with
+the sorted spelling — `jane+john` — whichever order you happened to type.
+
 #### The name collision, and why it is harmless
 
 `+` is a legal Jellyfin username character:
@@ -165,7 +175,7 @@ Download the release `.zip`, extract it into a `WatchedTogether` folder inside y
 
 On the shared device, at the Jellyfin login screen:
 
-- **Username:** `alice+bob` (the members' usernames, joined with `+`)
+- **Username:** `alice+bob` (the members' usernames, joined with `+`, in any order)
 - **Password:** your own
 
 That is the whole setup. The account is created on first use and reused from then on. Add a third
@@ -177,7 +187,8 @@ If you would rather provision groups explicitly — or you have turned auto-crea
 
 1. Go to **Dashboard → Plugins → Watched Together**.
 2. Under **Create a group**, select **two or more** members.
-3. Optionally give the account a name. Left blank, the member names are joined with `+`.
+3. Optionally give the account a name. Left blank, the member names are sorted alphabetically and
+   joined with `+`.
 4. Click **Create group**.
 
 Either way, a new user appears in your user list and can be renamed like any other.