refactor: filter transient errors from Sentry

Problem

Database statement timeout errors (SQLSTATE 57014) and context cancellation errors are being reported to Sentry, creating noise and false alerts. These are transient, expected errors that should not trigger alerts.

Root Cause

All errortracking.Capture calls in the codebase report errors directly without filtering transient errors.

Change

• Add centralized errorreporting.Capture(ctx, err, opts...) wrapper that filters:
  • context.DeadlineExceeded
  • context.Canceled
  • PostgreSQL QueryCanceled (SQLSTATE 57014)
• Wrapper automatically adds WithContext and WithStackTrace, simplifying call sites
• Replace all errortracking.Capture calls with the new wrapper
• Ensure all error capture sites have logging before capture for visibility of filtered errors
• Standardize log-then-capture order across all call sites for consistency

Rationale

Centralizing the filtering logic ensures consistent behavior across the codebase and simplifies future maintenance. The simplified API reduces boilerplate at call sites. Adding logging before capture ensures transient errors remain visible in logs even when filtered from Sentry.

Test Plan

• Unit tests for isTransientError covering all filtered error types
• Verified all modified packages compile and existing tests pass