v1.24.1

![logto-changelog-2025-02-v2 (1)](https://github.com/user-attachments/assets/becf45d6-54e6-486e-bb99-a284e43301d8)

## New connectors:

- X (Twitter) social connector
- Slack social connector
- LinkedIn social connector
- Line social connector
- Amazon social connector

## Bug fixes

- https://github.com/logto-io/logto/commit/cb261024b6d8ce1a708d2359d8843aa052aaff01: fix cli add offical connectors command missing connectors bug
  Fix the bug when running the cli commend logto connectors add --official, only 8 connectors are fetched from npm registry.
  This fix update logic to query additional pages of results when fetching connectors from the npm registry.
- https://github.com/logto-io/logto/commit/0b785ee0d8e1156607f5185c51e9a21fbae76a4d: display JWKS URI on application details page
- https://github.com/logto-io/logto/commit/e7accfdab9c646dfe60dd0728c9566823fe18188: prevent i18n context contamination by using request-scoped instances
  This bug fix resolves a concurrency issue in i18n handling by moving from a global i18next instance to request-scoped instances.

    ### Problem

    When handling concurrent requests:

    -   The shared global `i18next` instance's language was being modified via `changeLanguage()` calls.
    -   This could lead to race conditions where requests might receive translations in unexpected languages.
    -   Particularly problematic in multi-tenant environments with different language requirements.

    ### Solution

    -   Updated `koaI18next` middleware to create a cloned i18next instance for each request.
    -   Attach the request-scoped instance to Koa context (`ctx.i18n`) All subsequent middleware and handlers should now use `ctx.i18n` instead of the global `i18next` instance.
    -   Maintains the global instance for initialization while preventing cross-request contamination
-   a5990ec57: fixes an incorrect condition check in the verification code flow where `isNewIdentifier` was using inverted logic for email and phone comparisons.

    ### Changes

    -   Corrected `isNewIdentifier` boolean logic to use `identifier.value !== user.primaryEmail` for email checks
    -   Fixed phone number comparison to properly use `identifier.value !== user.primaryPhone`

    ### Impact

    This fixes a regression where:

    -   Verification codes for existing emails/phones were incorrectly using the`BindNewIdentifier` template
    -   New identifiers were mistakenly getting the `UserPermissionValidation` template
    -   Affected both email and phone verification flows
 
-   28643c1f1: fix the email/phone identifier conflict handling logic during user registration.

    When a user attempts to register with an email/phone that already exists:

    ### Previous Behavior

    "Sign in instead" modal will be shown when:

    -   The email/phone identifier has been verified through a verification code validation
    -   Identifier type (email/phone) was enabled in sign-in methods

    This caused an issue when:

    -   Only password authentication method was enabled in the sign-in method settings.
    -   When users clicked "Sign in instead" action button, the API call will throw an sign-in method not enabled error. Which is confusing for the user.

    Expected behavior: Show the "Email/phone already exists" error modal directly. If only password authentication is enabled. User should not be able to sign in with email/phone directly.

    ### Fixed Behavior

    Shows the "Sign in instead" modal if:

    -   The email/phone identifier type is enabled in the sign-in method settings and the verification code is enabled for the identifier.

    Otherwise, shows the "Email/phone already exists" error modal directly.

-   bd18da4cf: properly filter WeChat connectors by platform (Web | Native) in SSR sign-in experience settings

    Previously, platform-based social connector filtering was applied during the sign-in experience settings fetch process but not in the SSR sign-in experience data. As a result, platform-specific connectors were not correctly filtered when rendering the page using SSR data.

    This update ensures that the same filtering logic is applied to SSR sign-in experience data, resolving the issue.

    Affected connectors: WeChat Web and WeChat Native.