[eli-r-ph]

💡 Motivation and Context

Stacked on #1034. The v1 send path followed any redirect, so a 307 or 308 from the ingestion host could make the SDK resend event data to another host or over plain HTTP. The 7.x async client had a guard for this, which was lost when v0 was removed. This PR restores it for both clients.

Changes

• Capture follows a 307 or 308 only to the origin of host, at most 5 times, with the same body and headers.
• Any other redirect fails the batch and reaches on_error with the redirect status.
• Migration guide and changeset updated.

💚 How did you test it?

• Same-origin redirects are followed with an identical body.
• Redirects to another host, port or scheme, or a 302, send only one request.
• A redirect loop stops after 6 requests.
• Removing the origin check fails 5 tests.

🤖 Agent context

Autonomy: Human-driven (agent-assisted)

Written with Cursor (Claude) under the direction of the assignee. Turning redirects off entirely was rejected because it would break same-origin proxies.

🤖 Generated with Claude Code

[dustinbyrne]

AI-assisted review.

The shared sender now restricts capture redirect replay to the configured origin across both clients and capture lanes. Current CI and compliance passed, and the major changeset documents the intentional restriction. Two optional comments cover IDNA hostname equivalence and redirect logging.