Add ConvexProviderWithAuthKit for WorkOS AuthKit integration

[nicknisi]

Summary

• Add ConvexProviderWithAuthKit component for integrating Convex with WorkOS AuthKit
• Create new react-authkit package with proper build configuration
• Add @workos-inc/authkit-react as a dev dependency for testing

Changes

• src/react-authkit/ConvexProviderWithAuthKit.tsx: New provider component that wraps ConvexProviderWithAuth and adapts WorkOS's auth hook structure
• src/react-authkit/index.ts: Export the new component
• react-authkit/package.json: Package configuration for the new module
• api-extractor-configs/react-authkit-api-extractor.json: API extractor configuration for type definitions
• package.json: Added @workos-inc/authkit-react dev dependency

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[thomasballinger]

Added in get-convex/convex-backend@2f40066, pulled out into another package.

[thomasballinger]

@nicknisi since this fetchAccessToken can't actually force a refreshed token this is breaking the state machine, looking into whether we can relax this or we really want to expect a refreshed token

[thomasballinger]

I see that client.getAccessToken() has a forceRefresh, but agree that this is unnecessary if we can trust the AuthKit client to always have fresh-enough auth. Alternately we can build a new interface that allows WorkOS to tell us when a token has been refreshed.

The time the Convex client calls fetchToken with forceRefreshToken: true are

1. the server says the previous token has expired, so before we throw an error on the client we're getting a new token
2. the token has an expiration time that is two seconds (configurable, 2s is the default) away
3. the client is just coming online and just sent in the cached token, now we want a fresh token so it will have the full expiration time on it (we could calculate instead of re-requesting if we trusted the client not to have clock skew)

In case (3), if the token returned is not different than the previous token, the Convex client gives up on automated refreshing. This is the only behavior that needs to be changed, but in order to make other changes to the JWT instantly reactive (the user changes orgs, changes their, name, etc.).

Also I want to look into whether we're properly reactive to changes in the JWT, which are intended to be communicated by the identity of fetchToken changing (a new fetchToken is interpreted to mean it should be called again)

Just making a note, will get back to this later.