Clarify that servers may choose not to use M_USER_DEACTIVATED when they don't know who is asking. (#2246)

Co-authored-by: Andrew Morgan <1342360+anoadragon453@users.noreply.github.com>

changelogs/client_server/newsfragments/2246.clarification

@@ -0,0 +1 @@
+Clarify that servers may choose not to use `M_USER_DEACTIVATED` at login time, for example for privacy reasons when they can't authenticate deactivated users.

changelogs/client_server/newsfragments/2250.clarification

@@ -0,0 +1 @@
+Minor grammatical fix in the Secrets module description.

content/client-server-api/modules/secrets.md

@@ -59,7 +59,7 @@ clients will try to use the default key to decrypt secrets.
 
 Clients that want to present a simplified interface to users by not supporting
 multiple keys should use the default key if one is specified. If no default
-key is specified, the client may behave as if there is no key is present at
+key is specified, the client may behave as if no key is present at
 all. When such a client creates a key, it should mark that key as being the
 default key.
 

data/api/client-server/login.yaml

@@ -262,6 +262,8 @@ paths:
                 or the requested device ID is the same as a cross-signing key
                 ID.
               * `M_USER_DEACTIVATED`: The user has been deactivated.
+                Servers MAY instead use `M_FORBIDDEN` when they can no longer authenticate
+                the deactivated user (e.g. their password has been wiped).
           content:
             application/json:
               schema: