fix(adapter-posthog): don't start local-evaluation polling from POSTHOG_PERSONAL_API_KEY

[sarmah-rup]

Problem

The default postHogAdapter forwards POSTHOG_PERSONAL_API_KEY and featureFlagsPollingInterval: 10_000 into the runtime posthog-node client. In posthog-node, a personal API key enables local evaluation, which starts a per-process feature-flag poller.

On serverless deployments each warm process runs its own 10s poller, producing large volumes of PostHog feature-flag requests unrelated to real traffic.

Root cause: POSTHOG_PERSONAL_API_KEY is only needed for provider data discovery (getProviderData), which reads it independently of the runtime client. The two concerns were coupled only in the default singleton.

Changes

The default adapter no longer forwards the personal API key or polling interval to the runtime client. Local evaluation remains fully available by constructing the adapter explicitly with createPostHogAdapter and passing personalApiKey / featureFlagsPollingInterval in postHogOptions — matching the workaround described in the issue.

Testing

Added a regression test asserting the default runtime client is constructed without personalApiKey / featureFlagsPollingInterval even when POSTHOG_PERSONAL_API_KEY is set.

Note / scope

If you'd prefer an explicit opt-in flag to re-enable local evaluation on the default adapter instead (issue option 2), happy to adjust.

Closes #393

[vercel]

@sarmah-rup is attempting to deploy a commit to the Vercel Labs Team on Vercel.

A member of the Team first needs to authorize it.