Improve retry queue and backpressure behavior

Summary

Improve retry queue behavior and define backpressure/overflow semantics.

Why

sdk-specs marks retry-queue and event-batcher as applicable to both client and server SDKs. Backend SDKs should retain retryable failed deliveries and make queue overflow behavior explicit.

Current status

PostHog.Sender batches by size/time, but after PostHog.API.batch/2 the sender clears state regardless of HTTP result. There is no durable/in-memory retry queue behavior for retryable failures, and no explicit full-queue/backpressure policy was found.

Python has a related queue/backpressure issue: https://github.com/PostHog/posthog-python/issues/146.

Suggested scope

• Retain events when delivery fails with retryable network/5xx/429-style errors.
• Drop or acknowledge non-retryable failures according to documented policy.
• Define queue capacity and overflow behavior: drop oldest/newest vs block/backpressure.
• Emit warnings/telemetry/metrics when events are dropped or retrying.
• Serialize concurrent flushes and preserve FIFO best effort.
• Add tests for success, retryable failure, non-retryable failure, and overflow.

References

• https://github.com/PostHog/sdk-specs/blob/main/openspec/specs/retry-queue/spec.md
• https://github.com/PostHog/sdk-specs/blob/main/openspec/specs/event-batcher/spec.md

Start with PostHog.Sender and the PostHog.API.batch/2 call, then compare the retry-queue and event-batcher specifications linked in the issue. Define the queue, failure, overflow, concurrency, and telemetry behavior before implementing it. Done means tests cover successful delivery, retryable and non-retryable failures, and overflow.