[PM-27086] Update InputPasswordComponent MDX

libs/auth/src/angular/input-password/input-password.mdx

@@ -6,8 +6,8 @@ import * as stories from "./input-password.stories.ts";
 
 # InputPassword Component
 
-The `InputPasswordComponent` allows a user to enter master password related credentials.
-Specifically, it does the following:
+The `InputPasswordComponent` allows a user to enter a new master password for the purpose of setting
+an initial password or changing an existing password. Specifically, it does the following:
 
 1. Displays form fields in the UI
 2. Validates form fields
@@ -47,14 +47,14 @@ those values as needed.
 
 **Optional (sometimes)**
 
-These two `@Inputs` are optional on some flows, but required on others. Therefore these `@Inputs`
-are not marked as `{ required: true }`, but there _is_ component logic that ensures (requires) that
-the `email` and/or `userId` is present in certain flows, while not present in other flows.
+These `@Inputs` are optional on some flows, but required on others. Therefore these `@Inputs` are
+not marked as `{ required: true }`, but there _is_ component logic that ensures (requires) that the
+`email` and/or `userId` is present in certain flows, while not present in other flows.
 
 - `email` - allows the `InputPasswordComponent` to use the email as a salt (if needed)
 - `userId` - allows the `InputPasswordComponent` to do things like get the user's `kdfConfig`,
-  verify that a current password is correct, and perform validation prior to user key rotation on
-  the parent
+  verify that a current password is correct, and perform validation prior to user key rotation (if
+  selected) on the parent
 
 **Optional**
 
@@ -102,8 +102,9 @@ Used in scenarios where we do have an existing and authed user, and thus an acti
 
 - A "just-in-time" (JIT) provisioned user joins a master password (MP) encryption org and must set
   their initial password
-- A "just-in-time" (JIT) provisioned user joins a trusted device encryption (TDE) org with a
-  starting role that requires them to have/set their initial password
+- A "just-in-time" (JIT) provisioned user joins a trusted device encryption (TDE) org with the reset
+  password permission ("manage account recovery") from the start, which requires them to have/set
+  their initial password
   - A note on JIT provisioned user flows:
     - Even though a JIT provisioned user is a brand-new user who was “just” created, we consider
       them to be an “existing authed user” _from the perspective of the set-password flow_. This is
@@ -113,8 +114,9 @@ Used in scenarios where we do have an existing and authed user, and thus an acti
       registration when a user reaches the `/finish-signup` or `/trial-initiation` page to set their
       initial password, their account does not yet exist in the database, and will only be created
       once they set an initial password.
-- An existing user in a TDE org logs in after the org admin upgraded the user to a role that now
-  requires them to have/set their initial password
+- An existing user in a TDE org logs in after an org admin upgraded the user to have the reset
+  password persmission ("manage account recovery"), which now requires the user to have/set their
+  initial password
 - An existing user logs in after their org admin offboarded the org from TDE, and the user must now
   have/set their initial password<br /><br />
 
@@ -122,7 +124,7 @@ Used in scenarios where we do have an existing and authed user, and thus an acti
 
 Used in scenarios where we simply want to offer the user the ability to change their password:
 
-- User clicks an org email invite link an logs in with their password which does not meet the org's
+- User clicks an org email invite link and logs in with their password which does not meet the org's
   policy requirements
 - User logs in with password that does not meet the org's policy requirements
 - User logs in after their password was reset via Account Recovery (and now they must change their
@@ -154,8 +156,8 @@ which form field UI elements get displayed.
 
 ### Difference between `SetInitialPasswordAccountRegistration` and `SetInitialPasswordAuthedUser`
 
-These two flows are similar in that they display the same form fields and only generate new
-credentials, but we need to keep them separate for the following reasons:
+These two flows are similar in that they display the same form fields, but we need to keep them
+separate for the following reasons:
 
 - `SetInitialPasswordAccountRegistration` involves scenarios where we have no existing user, and
   **thus NO active account `userId`**: