Breadcrumb eviction in Scope.addBreadcrumb is reported as a discarded log_item (buffer_overflow)

从 packages/core/src/scope.ts 中的 Scope.addBreadcrumb 开始，检查 eviction 如何调用 recordDroppedEvent。复现包含超过 maxBreadcrumbs 个条目的情况，然后使用仓库中现有的 scope 行为测试（如果有）验证 breadcrumb eviction 不再显示为 buffer_overflow/log_item。

Is there an existing issue for this?

• I have checked for existing issues https://github.com/getsentry/sentry-javascript/issues
• I have reviewed the documentation https://docs.sentry.io/
• I am using the latest SDK release https://github.com/getsentry/sentry-javascript/releases

How do you use Sentry?

Sentry Saas (sentry.io)

Which SDK are you using?

@sentry/nextjs

SDK Version

10.73.0

Framework Version

Next 16.3.4

Link to Sentry event

No response

Reproduction Example/SDK Setup

Any app that adds more than maxBreadcrumbs (default 100) breadcrumbs to a scope.

Steps to Reproduce

1. Keep a scope alive long enough to add 101 breadcrumbs (a long-lived server scope, or a browser page with console/fetch/click breadcrumbs).
2. Look at the client reports the SDK sends, or at Sentry → Stats → Outcomes for the project.

Expected Result

Breadcrumb eviction from the ring buffer is not a discarded log item. Either it is not reported as a client report at all (a breadcrumb is context, and 100 is the intended cap), or it is reported under a breadcrumb-shaped reason/category rather than log_item.

Actual Result

Scope.addBreadcrumb records a client report with reason buffer_overflow and category log_item every time the breadcrumb buffer evicts an entry:

// packages/core/src/scope.ts (develop), same in @sentry/core 10.73.0 build/cjs/scope.js:394
this._breadcrumbs.push(mergedBreadcrumb);
if (this._breadcrumbs.length > maxCrumbs) {
  this._breadcrumbs = this._breadcrumbs.slice(-maxCrumbs);
  this._client?.recordDroppedEvent('buffer_overflow', 'log_item');
}

In Sentry's Stats page this shows up as discarded log items, client_discard · buffer_overflow, and in our project it dwarfs accepted logs: 84,981,094 "discarded" against 1,692,344 accepted log items over 7 days. We spent an investigation working out that none of those were log lines: the logs buffer flushes at 100 items / 800 KB / 5 s and never discards for this reason, so the only source of buffer_overflow · log_item in the SDK is breadcrumb eviction. The mislabel makes the Stats page read as if 98% of logs are lost in-process, when nothing is.

Suggested fix: drop the recordDroppedEvent call in addBreadcrumb, or give it its own reason/category so it cannot be read as log loss.