* Stop Sentry from capturing tRPC loggerLink noise as errors captureConsoleIntegration (levels: ["error"]) was scraping the raw console.error call that trpc's loggerLink makes for failed queries, producing spurious Sentry issues whose title/message was just the CSS-styled printf format string (e.g. "%c << query #1 %cstatusPage.getMonitor%c %O") instead of the actual error (OPENSTATUS-FRONTEND-ET, OPENSTATUS-FRONTEND-E5). Replace the default logger with one that reports the real error to Sentry directly via captureException and only logs to the console (never console.error) in development, across dashboard, status-page, and web's tRPC client/server setups. * Extract tRPC Sentry logger into shared helper, log errors in dev console Addresses PR review: the loggerLink callback was duplicated across all 6 tRPC client/server setups. Extract it into a per-app `sentryLoggerLink()` factory in each `shared.ts` (matching the repo's existing per-app tRPC shared-module convention) so the error-reporting logic lives in one place per app. Also fixes a dev-mode gap: failed queries were captured to Sentry and then early-returned before the console.log fallback, hiding them from the local console. They now console.warn the path + error in development before returning. * Don't attach raw tRPC input to Sentry error reports Addresses PR review (P1): capturing opts.input persisted request payloads to Sentry on every failed query — including page passwords, subscriber tokens, and email addresses. Attach only the operation path, which is enough to identify the failing procedure without leaking secrets. --------- Co-authored-by: Claude <noreply@anthropic.com>