feat: add opt-in ignoredSpanOps filter for Sentry (2.4.0)

[benminer]

Summary

Adds an opt-in filters.ignoredSpanOps option, passed to Sentry as ignoreSpans. It defaults to [], so nothing changes for consumers until they set it.

Each consumer decides which ops to drop. For example, agentic-api will set:

filters: { ignoredSpanOps: ['middleware.express', 'router.express'] }

Why agentic-api wants this: those two ops are about 90% of its Sentry spans. Over the last 7 days in prod: middleware.express 34M and router.express 11M, against 2.4M for http.server. They are why we keep hitting the Sentry performance quota.

How it works: Sentry 10's ignoreSpans drops matching child spans on the client before sending, re-parents their children, and records them as client discards. It works on the SentrySpanProcessor path that agentic-api uses with enableOtel: true. OTLP/Tempo export is unchanged. Sentry 11 has the same option, so this carries over when we upgrade.

Also updates the biome.json schema version to match the installed CLI (2.5.15).

Context

We're staying on Sentry 10 for now. Sentry 11 drops SentrySpanProcessor, so OTel spans can't go to Sentry and Tempo at the same time, and Sentry is our main trace UI.

Test plan

• npm run typecheck && npm run lint && npm test (57 passing; tests check the client's ignoreSpans with ops set and with the default)
• CI on Node 20.20.2 and 24.x
• After merge: run the release workflow, then bump agentic-api to 2.4.0 with @sentry/node pinned to 10.76.2 and ignoredSpanOps set. Check in staging that middleware.express and router.express no longer show up in Sentry.

🤖 Generated with Claude Code