Add request-scoped context and web middleware helpers

[marandaneto]

Summary

Add request-scoped identity/context support to the Rust SDK, plus middleware/tracing-header helpers for common Rust web frameworks.

Motivation

Python has contexts (new_context, identify_context, set_context_session, tag) and Django middleware that can apply identity/session metadata to all events captured during a request. Go has request-context helpers and middleware. Rust currently requires callers to pass distinct_id, $session_id, and shared properties manually for each capture, exception, and feature flag evaluation.

This makes it harder to connect backend Rust events/errors/flag evaluations to frontend sessions and replays, especially when using PostHog JS tracing headers:

• X-PostHog-Distinct-Id
• X-PostHog-Session-Id

Proposed scope

Provide a Rust-native way to set request-scoped PostHog context and framework integrations that populate it from incoming requests.

Possible API shape:

let ctx = PostHogContext::new()
    .distinct_id("user_123")
    .session_id("session_uuid")
    .property("request_id", request_id)?;

client.capture_with_context(ctx.clone(), event).await?;
let flags = client.evaluate_flags_with_context(ctx.clone(), options).await?;
client.capture_exception_with_context(&error, ctx).await?;

Or, if there's a more idiomatic Rust approach, use task-local/request-extension state and helpers.

Middleware candidates:

• tower/axum first, since this covers a broad set of Rust web apps.
• Actix support can be part of this issue or a follow-up depending on implementation size.

Middleware should be able to:

• Extract X-PostHog-Distinct-Id and X-PostHog-Session-Id from incoming requests.
• Attach request-scoped defaults for captures and exceptions.
• Make the request-scoped distinct ID available for feature flag evaluation.
• Allow an authenticated server-side distinct ID to override client-controlled tracing headers for security-sensitive events/decisions.

Acceptance criteria

• Rust SDK has a request-scoped context API for distinct ID, session ID, and shared properties/tags.
• Captures, exceptions, and feature flag evaluations can consume this context.
• At least one middleware integration (preferably tower/axum) extracts PostHog tracing headers and populates context.
• Docs clearly warn that tracing headers are client-controlled analytics context, not authentication/authorization.
• Tests cover context propagation and header extraction.

[cat-ph]

this also covers the context need that came up in the panic-autocapture PR (#157). worth explicitly folding panics into the scope here:

• Panic autocapture is always personless today (Event::new_anon), and unlike capture_exception there's no per-call site to thread a context through, so the explicit capture_exception_with_context(err, ctx) shape can't attribute panics. They only benefit from the ambient/implicit variant (the task-local/request-extension state mentioned above).
• Implementation note for that path: the context should probably be read at capture/enqueue time on the panicking thread, the background worker that actually sends the event doesn't have it, and the panic hook routes through the global client

tl;dr: as long as the ambient/task-local path lands (not just the explicit *_with_context calls), identified panics should come for free.