Fix log count in client reports

[adinauer]

📜 Description

Previously discarded log count was only increased by 1 for the whole batch instead of counting discarded log items.

💡 Motivation and Context

Have correct client reports.

💚 How did you test it?

📝 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.

🔮 Next steps

[sentry]

Bug: LogItem deserialization failures do not record lost items, leading to inaccurate client reports, unlike Transaction items.
_{Severity: CRITICAL | Confidence: 0.95}

🔍 Detailed Analysis

When a LogItem envelope item fails to deserialize via envelopeItem.getLogs(options.getSerializer()) (either returning null or throwing an exception), the code responsible for recording lost items is skipped. This occurs because the recordLostEventInternal and executeOnDiscard calls are conditionally placed inside an if (logs != null) block. Consequently, client reports will not accurately reflect all lost LogItem events, specifically those that are malformed and fail deserialization. This behavior is inconsistent with how Transaction items are handled, where a lost item is recorded regardless of deserialization success.

💡 Suggested Fix

Move the recordLostEventInternal and executeOnDiscard calls for LogItem outside the if (logs != null) block. This ensures that a lost item is recorded even if LogItem deserialization fails, aligning its behavior with Transaction item handling.

🤖 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/clientreport/ClientReportRecorder.java#L104-L110

Potential issue: When a `LogItem` envelope item fails to deserialize via
`envelopeItem.getLogs(options.getSerializer())` (either returning `null` or throwing an
exception), the code responsible for recording lost items is skipped. This occurs
because the `recordLostEventInternal` and `executeOnDiscard` calls are conditionally
placed inside an `if (logs != null)` block. Consequently, client reports will not
accurately reflect all lost `LogItem` events, specifically those that are malformed and
fail deserialization. This behavior is inconsistent with how `Transaction` items are
handled, where a lost item is recorded regardless of deserialization success.

_{Did we get this right? 👍 / 👎 to inform future reviews.}

[github-actions]

Performance metrics 🚀

	Plain	With Sentry	Diff
Startup time	325.69 ms	388.33 ms	62.64 ms
Size	1.58 MiB	2.12 MiB	553.15 KiB

Baseline results on branch: main

Startup times

Revision	Plain	With Sentry	Diff
806307f	357.85 ms	424.64 ms	66.79 ms
ee747ae	554.98 ms	611.50 ms	56.52 ms
17a0955	372.53 ms	446.70 ms	74.17 ms
2124a46	319.19 ms	415.04 ms	95.85 ms
9fbb112	404.51 ms	475.65 ms	71.14 ms
b6702b0	395.86 ms	409.98 ms	14.12 ms
ee747ae	357.79 ms	421.84 ms	64.05 ms
27d7cf8	314.17 ms	347.00 ms	32.83 ms
9fbb112	361.43 ms	427.57 ms	66.14 ms
96449e8	361.30 ms	423.39 ms	62.09 ms

App size

Revision	Plain	With Sentry	Diff
806307f	1.58 MiB	2.10 MiB	533.42 KiB
ee747ae	1.58 MiB	2.10 MiB	530.95 KiB
17a0955	1.58 MiB	2.10 MiB	533.20 KiB
2124a46	1.58 MiB	2.12 MiB	551.51 KiB
9fbb112	1.58 MiB	2.11 MiB	539.18 KiB
b6702b0	1.58 MiB	2.12 MiB	551.79 KiB
ee747ae	1.58 MiB	2.10 MiB	530.95 KiB
27d7cf8	1.58 MiB	2.12 MiB	549.42 KiB
9fbb112	1.58 MiB	2.11 MiB	539.18 KiB
96449e8	1.58 MiB	2.11 MiB	539.35 KiB

Previous results on branch: fix/client-reports-logs-count

Startup times

Revision	Plain	With Sentry	Diff
0f3f81c	303.10 ms	357.29 ms	54.18 ms
73f5841	374.90 ms	449.98 ms	75.08 ms

App size

Revision	Plain	With Sentry	Diff
0f3f81c	1.58 MiB	2.12 MiB	551.81 KiB
73f5841	1.58 MiB	2.12 MiB	553.18 KiB