fix(sentry-tracing): report exceptions no filter matches
Problem
SentryInterceptor.shouldReport returned filters.some(f => !(exception instanceof f.type && (!f.filter || f.filter(exception)))). SentryCustomInterceptor passes filters: [], and [].some(...) is false, so no exception was ever sent to Sentry. With several filters the logic was also inverted: an exception matched by one filter was still reported as long as another did not match it.
Fix
Skip an exception only when some filter matches it: !filters.some(({ type, filter }) => exception instanceof type && (!filter || filter(exception))); no options / no filters still means "report everything". Same logic as PosthogErrorInterceptor.shouldReport.
Tests
New sentry.interceptor.spec.ts: no options, {} and filters: [] report; with an HttpException < 500 filter plus a type-only filter, matched exceptions are skipped and the others reported.
Notes
Not built or run locally.
Summary by cubic
Fixes SentryInterceptor.shouldReport so exceptions are only skipped when a filter matches, instead of the previous inverted logic. The old code used filters.some(!match): an empty filter list never reported anything, and an exception matched by one filter was still reported whenever another filter didn't match it. Now no options or no filters reports everything, and an exception is skipped only when one filter matches it.
Also makes SentryCustomInterceptor respect the tenant's Sentry switch: it reads the current request's resolved sentryEnabled setting the way SentryService.isEnabled does, so a tenant that turned Sentry off no longer has its errors sent. And it enables the HttpException < 500 filter that was already written in the file: client errors (4xx) are expected traffic and no longer spend the Sentry quota, while 5xx and non-HTTP errors are still reported.
Adds sentry.interceptor.spec.ts and sentry-custom.interceptor.spec.ts covering report behavior with no options, empty and populated filter lists, the 4xx/5xx split, and the tenant switch.