fix(account): bind managed group forwarding key UserID to the canonical member address

[SashaMIT]

Problem

Since 332003c, addGroupMember derives the forwarded key's UserID from the email embedded in the member's own primary public key:

const Email = getEmailFromKey(forwardeePublicKey) ?? email;
const userIDsForForwardeeKey = [{ email: Email, name: Email }];

The two internal branches diverge in what happens when that embedded email does not match the address being added:

• Private / other-org path: issues an ActivationToken, and acceptGroupInvitation explicitly re-checks extractedEmail !== forwardeeEmail and calls cloneKeyAndChangeUserIDs to rebind the key. Self-healing.
• Managed path (org key held): forwards a ready-to-use key with no activation step, so nothing ever corrects a mismatched UserID. The persisted group-member key can assert an email other than the address it is actually bound to, which surfaces in clients, audit views, and anywhere the key UserID is taken as identity.

Fix

On the managed path only, pass the canonical member address as the UserID — the address the key is actually issued for:

getInternalParameters(forwarderKey.privateKey, [{ email: canonicalEmail, name: canonicalEmail }], decryptedToken)

Applied to both variants of the flow (addGroupMemberApi and addGroupMemberKeysApi). The private path is intentionally unchanged: its activation flow performs the rebind, and preserving the key's own UserID there avoids a behavior change ahead of it.

Verification

tsc --noEmit on the edited file: identical diagnostic set before/after (17 pre-existing module-resolution errors from a shallow checkout without workspace install; zero errors attributable to this change). The diff uses only in-scope identifiers.

Made with Cursor