Option B — feat(auth): add createVerifier hook to the oauth config

[muralx]

One of two alternative shapes for the same capability — see #2 for the other (widening verify into a union). This variant keeps verify untouched and adds a creation hook instead. We intend to propose whichever reads better to the Skybridge maintainers upstream.

Shape

OAuthConfig gains an optional createVerifier(config), called once at boot at the exact point the framework builds its verifier today, defaulting to the built-in createJwksVerifier(config.verify). The config stays a data description of the deployment; createVerifier is the method that turns that data into the verifier, and a provider package returns both halves together — async preparation happens in the (already-async) provider, with the hook doing synchronous assembly at boot.

• Pro: verify keeps its existing type and required issuer — no union, no type alias, provider signatures untouched; one uniform creation path in setupOAuth. Net diff is 4 files, +148/−2.
• Con: an app hand-wiring a verifier without a provider package writes a one-line wrapper function instead of assigning the verifier object directly.

Changes

• createVerifier?: (config: OAuthConfig) => OAuthTokenVerifier on OAuthConfig, with docs on the contract (resolve AuthInfo or throw the SDK error classes, as with requireBearerAuth).
• setupOAuth: const verifier = (config.createVerifier ?? ((c) => createJwksVerifier(c.verify)))(config); the issuer boot guard is unchanged and still applies.
• Tests: custom verifier threads authInfo; 401 challenge with resource_metadata on rejection; metadata endpoints intact; hook called exactly once at boot with the resolved config; verify.issuer still required alongside a custom hook.
• Docs: custom-provider.mdx.

All 402 core tests pass; tsc and biome ci clean; the new tests were verified to fail with the implementation reverted.