Signature changes to @PostHogInternal APIs aren't caught by apiCheck #916

Summary

@PostHogInternal APIs are no longer covered by apiCheck, so a signature change that breaks posthog-server or a wrapper SDK can ship unnoticed.

Current behavior

build.gradle.kts on the 4.0 branch excludes them from the binary compatibility validator:

apiValidation {
    // APIs only wrapper SDKs and the SDK's own modules may call; not part of the public API.
    nonPublicMarkers.add("com.posthog.PostHogInternal")
}

These APIs are still called across things that release separately:

• posthog-server and posthog-android depend on posthog, and each has its own version.
• posthog-flutter, posthog-kmp and React Native (in posthog-js) build against published posthog-android versions.

Removing them from posthog/api/posthog.api was the right call for the public surface, but it also removed the only check that flagged a changed internal signature.

Expected behavior

A changed signature on an internal API that another module or wrapper SDK uses shows up in CI, and the author has to acknowledge it, without those APIs becoming public API again.

One possible implementation is a second dump that lists only @PostHogInternal declarations and is checked in CI the same way as apiCheck. Another is a CI job that compiles the wrapper SDKs' Android code against the current branch. The PR can decide.

Acceptance criteria

• Changing the signature of a @PostHogInternal API fails a CI check in this repo.
• The check is documented in CONTRIBUTING.md, including how to accept an intended change.
• @PostHogInternal APIs stay out of posthog/api/posthog.api.

Additional context

Raised in review of #881: #881 (comment). The marker itself came in with #904, which merged into #881.

This is build tooling, so no product label applies. It isn't about deciding which APIs should be internal.