fix(android): mark tombstone and ANR exits as reported when the event is dropped

[markushi]

📜 Description

The last reported marker (last_tombstone_report / last_anr_report) was only written as a side
effect of caching the envelope on disk. An event dropped by beforeSend never gets there, so the
same ApplicationExitInfo was turned into an event again at every app start.

ApplicationExitInfoHistoryDispatcher now writes the marker as well when captureEvent returns
SentryId.EMPTY_ID, through a new ApplicationExitInfoPolicy.markReported(long). The successful
path is unchanged.

💡 Motivation and Context

A discarded crash must stay discarded. This is how signal handler events already behave, because
OutboxSender deletes the outbox file independent of the result of beforeSend.

• resolves: Tombstone events discarded from beforeSend are re-reported on every app launch #5973
• resolves: JAVA-697

💚 How did you test it?

New test in ApplicationExitIntegrationTestBase, so it runs for both TombstoneIntegrationTest
and AnrV2IntegrationTest. It failed before the change and passes now. Full
:sentry-android-core:testReleaseUnitTest is green.

📝 Checklist

• I added GH Issue ID & Linear ID
• I added tests to verify the changes.
• No new PII added or SDK only sends newly added PII if sendDefaultPII is enabled.
• I updated the docs if needed.
• I updated the wizard if needed.
• Review from the native team if needed.
• No breaking change or entry added to the changelog.
• No breaking change for hybrid SDKs or communicated to hybrid SDKs.
• Public API changes reviewed by another Mobile SDK team member or implemented according to the develop docs spec.

🔮 Next steps

TombstonePolicy deletes the matching native outbox file before the capture, so native data cannot
come back if the merged event is lost. That is a separate defect.

[linear-code]

JAVA-697

[sentry]

📲 Install Builds

Android

🔗 App Name	App ID	Version	Configuration
SDK Size	io.sentry.tests.size	8.53.0 (1)	release

⚙️ sentry-android Build Distribution Settings

[0xadam-brown]

Nice to fix this 👍

Lgtm save for the ambiguity of the EMPTY_ID, as called out by SentryBot here.

[sentry]

Bug: When an EventProcessor returns null, no EventDropReason is set. This causes ApplicationExitInfoHistoryDispatcher to repeatedly report the same dropped event on subsequent app starts.
_{Severity: HIGH}

Suggested Fix

In SentryClient.processEvent, when an event is dropped because an EventProcessor returned null, set the EventDropReason.EVENT_PROCESSOR on the Hint. This will ensure that downstream consumers like ApplicationExitInfoHistoryDispatcher can correctly identify that the event was intentionally dropped and avoid re-processing it.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: sentry/src/main/java/io/sentry/SentryClient.java#L212-L218

Potential issue: In `SentryClient.processEvent`, if an `EventProcessor` returns `null`
to drop an event, the code records a `DiscardReason.EVENT_PROCESSOR` but fails to set an
`EventDropReason` on the associated `Hint`. This causes a downstream issue in
`ApplicationExitInfoHistoryDispatcher`, which relies on a non-null `EventDropReason` to
mark a report as processed by calling `policy.markReported()`. Without the drop reason,
the report is never marked, leading to the same application exit event (e.g., ANR,
tombstone) being reported repeatedly on every subsequent application start.