OutboxSender sends attachments as standalone envelopes

## What's happening?

When `OutboxSender` (sentry-java/Android) processes envelopes written to disk by sentry-native (e.g. after an NDK crash), it iterates each envelope item individually. Event and Transaction items go through `captureEvent`/`captureTransaction`, but any other item type — including Attachment — is wrapped in a brand-new single-item `SentryEnvelope` and sent standalone via `captureEnvelope`, instead of being sent together with the event that produced it.

## Why is it happening? (root cause)

This is `OutboxSender.processEnvelope` in `sentry/src/main/java/io/sentry/OutboxSender.java`. The loop dispatches Event/Transaction items via their dedicated capture calls, and falls through to a generic `else` branch for every other item type that wraps that single item in its own envelope and sends it immediately (around `OutboxSender.java#L124`, current `captureEnvelope(newEnvelope, hint)` call). There is no step that buffers non-event items and reassembles them into one outgoing envelope keyed by `event_id` before sending.

## Possible solutions (proposal, not yet decided)

* Buffer Attachment-type items encountered while iterating `envelope.getItems()`, converting each `SentryEnvelopeItem` into an `Attachment` (filename/content-type from the item header, bytes from `item.getData()`).
* When the Event or Transaction item is found, call `hint.addAttachments(buffered)` before `captureEvent`/`captureTransaction`, instead of sending each attachment through its own `captureEnvelope` call. `Hint` already supports `addAttachments(List)`, so this doesn't require a new envelope format.
* Handle item ordering (attachments may appear before or after the event item within the envelope) and the edge case of attachment-only envelopes (no event/transaction present), which must still be sent standalone.
* Add an explicit size check before merging: if attaching would push the combined envelope over the max envelope size, fall back to sending that attachment standalone (or drop it) rather than risking the whole event getting rejected.
* Only merge Attachment-type items — leave other non-event item types (session, user feedback, etc.) on their current per-item send path to avoid changing unrelated behavior.
* Extend `OutboxSenderTest.kt` to cover reassembly, mixed item ordering, and the no-event fallback.
* Estimated scope: mostly contained to `OutboxSender.java` and its test, no protocol/API changes, no server-side work required — ingestion already accepts combined event+attachment envelopes (used by JS and other SDKs today) and will keep supporting standalone attachments for legacy SDK versions regardless.

## User Impact

* Quota/cost impact: Relay has no filter stage for standalone attachments (only `processing/errors/` has one), so when an event is dropped by an inbound filter, its standalone attachment still gets ingested and billed — landing as an orphan the customer can't even see, since there's no event to attach it to. Riot Games hit this concretely, ingesting roughly 10TB/day of attachments with ~90% having no associated event, and a live investigation (`INGEST-1167`) found Android/Java is currently the SDK with the highest volume of standalone attachments. Ingest is shipping a server-side stopgap (discard orphaned attachments at the filter stage), but fixing `OutboxSender` removes the root cause on the Android/Java side rather than relying on ingest to keep mopping up after it.
* Mainly affects Android apps using sentry-native (NDK crash reporting) and hybrid SDKs (Unity, Flutter, React Native, etc.) layered on top of sentry-android, since they're the ones writing envelopes to the outbox folder that `OutboxSender` later fans out.

## History of the issue

The design is incidental, not deliberate. The original envelope-pickup code (`getsentry/sentry-android#89`, `getsentry/sentry-android#145`, 2019) only handled Event items; every other item type was simply logged as ignored, with a `// TODO: Handle attachments and other types` comment left in place. In January 2021, `getsentry/sentry-java#1158` ("OutboxSender supports all envelope item types") closed that TODO by adding the current catch-all branch: wrap any non-event item in its own envelope and send it immediately. That was a pragmatic fix to stop dropping items, not a considered protocol decision — there's no historical discussion of envelope size limits, item ordering, or ingestion semantics tied to it.

## Other useful context

This surfaced from [a cross-SDK discussion]() (also [here]()) about disallowing standalone attachments at the protocol/spec level (develop-docs). Ingestion will keep accepting standalone attachments indefinitely to support already-shipped legacy SDK versions, so this fix is about sentry-java emitting the preferred combined-envelope format going forward, not a breaking or urgent change. If the spec formally disallows standalone attachments before this is fixed, `OutboxSender`'s native-outbox path should get an explicit documented exception until this issue is resolved.

Action taken on behalf of Adam Brown.