feat(server): Add request context support

[dustinbyrne]

💡 Motivation and Context

Server-side SDK users handling frontend requests need a safe way to carry PostHog frontend tracing context into backend captures. This adds request-scoped context support for posthog-server, so captures and exception captures can inherit frontend distinct/session metadata while still preserving explicit SDK call overrides.

💚 How did you test it?

• ./gradlew :posthog-server:test --tests "com.posthog.server.PostHogRequestContextTest" --tests "com.posthog.server.PostHogEvaluateFlagsTest"
• make checkFormat
• ./gradlew :posthog-server:test
• git diff --check
• make api

📝 Checklist

• I reviewed the submitted code.
• I added tests to verify the changes.
• I updated the docs if needed.
• No breaking change or entry added to the changelog.

If releasing new changes

• Added a changeset file (.changeset/request-context-server.md)

[greptile-apps]

Prompt To Fix All With AI

Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 1
posthog-server/src/test/java/com/posthog/server/PostHogEvaluateFlagsTest.kt:235-299
**Duplicate tests should be parameterized**

`evaluateFlags uses request context distinctId when omitted` and `evaluateFlags uses request context distinctId when null` are structurally identical — the only difference is calling `postHog.evaluateFlags()` vs `postHog.evaluateFlags(null)`. Per the team's preference for parameterized tests, these two cases should be collapsed into a single `@ParameterizedTest` (e.g. using a boolean parameter or a supplier for the call-under-test).

_{Reviews (1): Last reviewed commit: "fix: allow nullable request context dist..." | Re-trigger Greptile}