fix: guard false-positive on basic-auth accounts (identity != login)

Accounts whose primary sending identity differs from their login (basic
auth registers accountId from the typed login; OAuth from the identity
email) were force-re-authed on switch because the guard derived the
connected id only from the primary-identity email. Collect every
server-confirmed identifier (JMAP Session.username + primary-identity
email) and only re-auth when the target matches none. Excludes the
constructor username so a real desync still trips. Adds
JMAPClient.getSessionUsername().

lib/jmap/client.ts

@@ -61,6 +61,9 @@ export class RateLimitError extends Error {
 
 // JMAP protocol types - these are intentionally flexible due to server variations
 interface JMAPSession {
+  // The authenticated login (JMAP spec Session.username) — server-confirmed,
+  // unlike the client-side constructor username or the sending identity.
+  username?: string;
   apiUrl: string;
   downloadUrl: string;
   uploadUrl?: string;
@@ -3601,6 +3604,14 @@ export class JMAPClient implements IJMAPClient {
     return this.username || this.session?.accounts?.[this.accountId]?.name || '';
   }
 
+  // Server-confirmed authenticated login from the JMAP Session object. Use
+  // this (not getUsername(), which echoes the constructor arg, nor the
+  // sending identity) to verify a slot's token resolved to the expected
+  // account.
+  getSessionUsername(): string | undefined {
+    return this.session?.username;
+  }
+
   supportsEmailSubmission(): boolean {
     return this.hasCapability("urn:ietf:params:jmap:submission");
   }