feat(core): add createHttpClientWithPasskeyCredentials for dynamic credential filtering

[LiorAgnin]

Summary & Motivation

Add support for dynamically specifying allowCredentials when creating HTTP clients. This enables filtering which passkeys are shown during WebAuthn signing operations on a per-client basis.

Use case: When an app stores multiple users locally (each with their own passkey), this feature allows creating HTTP clients that only prompt for a specific user's passkey during signing. This improves UX by avoiding showing irrelevant passkeys in the WebAuthn prompt.

Changes:

• Add allowCredentials to CreateHttpClientParams type
• Add async createHttpClientWithPasskeyCredentials() method to TurnkeyClient
• Expose the new method in react-native-wallet-kit TurnkeyProvider

Example usage:

const client = await createHttpClientWithPasskeyCredentials({
  allowCredentials: [{
    id: credentialIdAsUint8Array,
    type: 'public-key',
  }],
})

How I Tested These Changes

• Verified TypeScript compilation
• Tested in a React Native app with multiple user profiles, confirming only the selected user's passkey appears during signing

Did you add a changeset?

Yes - brave-keys-filter.md with minor version bumps for @turnkey/core and @turnkey/react-native-wallet-kit.

These changes will be used at release time to determine what packages to publish and how to bump their version. For more context see this comment.

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit 1ccd6b6:

Sandbox	Source
@turnkey/example-react-components	Configuration

[moeodeh3]

Appreciate the pr, wondering if the changes in 1160 are sufficient for your use-case?

[LiorAgnin]

Appreciate the pr, wondering if the changes in 1160 are sufficient for your use-case?

@moeodeh3

PR 1160 covers the login flow well, but my use case involves maintaining separate authenticated clients per user profile for post-login operations. With 1160, I'd need to call overridePasskeyStamper before each operation, which introduces state management complexity and race condition risks in multi-profile apps. The factory pattern in this PR provides a cleaner per-client isolation. Happy to rebase on top of 1160 if you'd like both patterns available.