Fix: a duplicate group invite demoted a member who had already joined

[mpretty-cyro]

Issue #2215, reported with a reliable repro and against every Session Android version.

Receiving side

GroupManagerV2Impl.handleInvitation had no check for a group we are already in. It built a fresh ClosedGroupInfo and wrote it over the existing record, so a second invitation set invited back to true and reset joinedAtSecs to 0 — a joined member was demoted to "invited" and their join time was lost.

It now checks the same thing handlePromotion already checks — but conditionally, not literally. A literal group == null check would break re-invitation after a kick: handleKicked keeps the record with kicked = true, and an invitation that rebuilds it is the only way back in. The guard is therefore "already joined": present, and not invited, kicked or destroyed.

Why a bare guard would have been a regression

A second invitation still has to be answered. Our invite response is sent once, on approval, inside a runCatching whose failure is swallowed, and the admin marks us INVITE_ACCEPTED only on receiving it. So an admin whose copy was lost sees us as "Invite sent" indefinitely, and re-inviting is the only repair available to them — which means the reported demotion is what that repair did on our side.

Simply ignoring the duplicate would have removed the repair and left the admin stuck, with Resend visibly doing nothing. The already-joined path therefore sends the invite response and drops the invitation from our swarm — the parts of approval the admin depends on — without touching membership or joinedAtSecs. An admin member sends no response, because their membership is not established that way.

Admin side

inviteMembersInternal called setInvited() whatever state the member was in, and InviteContactsJob then wrote the send result over the top. Re-inviting someone who had accepted reset them in both places, so fixing only the first would have changed nothing observable.

Both now skip anyone already in the group: INVITE_ACCEPTED, or isAdminOrBeingPromoted(status) — the predicate BaseGroupMembersViewModel already uses for showAsAdmin/canPromote, which is admin || status in { PROMOTION_SENT, PROMOTION_ACCEPTED }. Naming the accepted statuses by hand would have missed a member whose promotion is still in flight, and the outcome of sending them another invitation says nothing about a membership they already have.

Note this half is defensive rather than load-bearing: promotions never reach InviteContactsJob (promoteMember sends and records its own results), canResendInvite is offered only for INVITE_SENT/INVITE_FAILED, and the invite picker excludes existing members. It closes the hole rather than a reachable regression.

Tests

GroupManagerV2ImplTest, synthetic group config only:

test	reverting
a second invitation leaves a joined group untouched	the guard
a second invitation is still answered, so the admin can stop showing us as invited	the acknowledgement
an admin member answers a second invitation without sending a response	the acknowledgement
a first invitation is written to the user's groups	— control, passes either way

The control exists so the negative tests cannot pass by never reaching the code.

The admin side has no test: GroupMember's state setters are native, so no JVM unit test can reach them.

Known limits, not addressed here

• The guard protects the device that handles the message. A linked device on an older build can still rebuild the demoted record and sync it back.
• Answering a duplicate invitation deletes it from our swarm, but a record already synced by another device is not undone.

Rebased on dev d29053ab48. Unit suite: 315 pass, 0 fail.