feature: don't request CAPABILITY after auth/login if they are returned in auth response

imapclients invalidates capabilities on login/auth/starttls as it should but login and auth often send capabilities in response, those can be used but they are cleaned too.

From rfc - https://datatracker.ietf.org/doc/rfc9051/

A server MAY include a CAPABILITY response code in the tagged OK
response to a successful LOGIN command in order to send capabilities
automatically. It is unnecessary for a client to send a separate
CAPABILITY command if it recognizes these automatic capabilities.

Here is debug log that demonstrates the problem (with creds removed) - T3 request can be avoided
T1 CAPABILITY\r\n* CAPABILITY IMAP4rev1 CHILDREN UNSELECT LITERAL+ NAMESPACE XLIST UIDPLUS ENABLE ID AUTH=PLAIN AUTH=XOAUTH2 IDLE MOVE\r\nT1 OK CAPABILITY Completed.\r\nT2 LOGIN "diana@example.com" "password"\r\n* CAPABILITY IMAP4rev1 CHILDREN UNSELECT LITERAL+ NAMESPACE XLIST UIDPLUS ENABLE ID IDLE MOVE\r\nT2 OK LOGIN Completed.\r\nT3 CAPABILITY\r\n* CAPABILITY IMAP4rev1 CHILDREN UNSELECT LITERAL+ NAMESPACE XLIST UIDPLUS ENABLE ID IDLE MOVE\r\nT3 OK CAPABILITY Completed.

No file or test is named. Start by tracing capability invalidation and response handling for LOGIN, AUTH, and STARTTLS, using the RFC 9051 excerpt and the debug exchange as the behavioral guide. Done means capabilities returned in a successful LOGIN or AUTH response are retained and no redundant CAPABILITY request is sent.