Allows a user to add a password which automatically creates and email
identity to enable email + password authentication for OAuth-only
accounts.
Gated behind a feature flag: `enableAccountPassword`
When a user does not have an email identity, allow them to set a
password:
<img width="762" height="284" alt="Screenshot 2026-08-13 at 14 52 53"
src="https://github.com/user-attachments/assets/70b4883a-ed38-488a-a1b7-908caa112a0b"
/>
Password modal:
<img width="519" height="423" alt="Screenshot 2026-08-13 at 14 56 57"
src="https://github.com/user-attachments/assets/56ac370d-9e6c-4b05-986f-3aa9a51826c2"
/>
Email identity has been created, allow unlinking and/or updating email
address or password:
<img width="764" height="285" alt="Screenshot 2026-08-13 at 14 55 04"
src="https://github.com/user-attachments/assets/5d9d7692-f4e3-4638-958d-15fefad01333"
/>
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* OAuth-only accounts can set a password from Sign-in methods.
* Added password visibility controls, validation guidance, and success
or error feedback.
* Sign-in methods display the account email when available.
* **Updates**
* Renamed “Account identities” to “Sign-in methods” throughout account
preferences.
* Standardized password requirements across password setup and reset
forms.
* Setting a password refreshes the current session and signs out other
sessions.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Summary
The email-change confirmation toast rendered a trailing `&sb=` ("...sent
to the other email&sb="). The dashboard parsed the auth-redirect URL
fragment with a naive `split('#message=')` that grabbed everything after
the key, including the empty `sb` origin marker the auth service appends
to every redirect fragment (an intentional, server-side Supabase-Auth
identifier so clients can tell a Supabase redirect from a third-party
OAuth one). The marker is working as designed; the bug is that the
dashboard wasn't parsing the fragment as URL params, so I fixed the
parse rather than the marker.
## Changes
- Parse the redirect fragment with `URLSearchParams` via a new
`parseRedirectMessage` helper, reading only the `message` key. Any other
trailing fragment param (the `sb` marker, or future ones) is now ignored
instead of being concatenated into the toast.
- Drop the manual `+`-to-space replacement. `URLSearchParams.get()`
already decodes form-encoded values, and the old `.replaceAll('+', ' ')`
would have clobbered a legitimately encoded `+`.
- Add unit tests for the helper: marker stripped, no hash, no `message`
key, `message` not first, and percent-encoded `+` preserved.
## Testing (Vercel preview)
The toast only reads the URL fragment, so the redirect can be simulated
directly. Do not use the real email round-trip on the preview: a real
confirm-link click is redirected to prod (the backend sets
`redirect_to`), not the preview build.
- [x] On the preview, log in and open the account preferences page with
this fragment appended:
`/account/me#message=Confirmation+link+accepted.+Please+proceed+to+confirm+link+sent+to+the+other+email&sb=`
— toast shows the clean sentence with no `&sb=`.
- [x] Open the same page with no fragment — no toast fires.
## Linear
- fixes GROWTH-938
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* Improved how success messages are read after redirect in account
identity preferences, so notifications now display the correct text more
reliably.
* Supported messages with spaces and special characters, including cases
where the message appears later in the URL fragment.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
fadymak