feat: bridge Better Auth UI to BTST v3 providers

[olliethedev]

Summary

• add client and server Better Auth adapters for the BTST v3 auth contracts
• source router, notifications, localization, identity refresh, and explicit permission checks from top-level StackProvider services
• keep the fork delta isolated to bridge/adapter/plugin surfaces so upstream component updates remain easy to sync
• add BTST v3 integration documentation and a retry-safe RC publishing workflow

Security behavior

• Better Auth's native permission hook is preserved unless permissionProvider or a custom can mapping is explicitly configured
• anonymous mapped permission checks fail closed
• permission batches that BTST's single resource/action contract cannot represent fail closed
• session changes refetch BTST identity before refreshing the router

Scope

The upstream standalone AuthUIProvider and auth/account/organization UI components are unchanged. createResource, useForm, and useListState are not introduced because Better Auth already owns these form/query flows and there is no corresponding BTST resource/list seam to adapt.

Verification

• pnpm test (65 tests)
• pnpm build
• pnpm lint (pre-existing warnings only)
• cd docs && pnpm build (68 static pages)
• built root, /client, and /server declarations expose the intended provider factories

Closes #17

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 8b29096deb

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Include the identity in server admin permission checks

When permissionProvider is "admin", Better Auth's server-side userHasPermission API needs the user being checked (normally userId: params.identity.id, or an explicit role) in the request body. This call only sends permissions, despite already requiring params.identity, so documented server configurations using the admin provider will have their authorization checks rejected or fail closed rather than evaluate that user's permissions.

Useful? React with 👍 / 👎.