[Feature][High] Add observability infrastructure: structured logging, error reporting, and performance telemetry

[numbers-official]

Summary

The extension has zero observability — no structured logging, no error reporting service, no performance telemetry, and no usage metrics. All 99 console statements use raw console.log/warn/error with no log levels, filtering, remote reporting, or ability to disable in production. This makes it impossible to diagnose user-reported issues, measure upload success rates, or detect regressions.

Evidence

No structured logging framework

All logging is via raw console.* calls scattered across the codebase:

• src/background/service-worker.ts — 30+ console statements
• src/services/UploadService.ts — 15+ console statements
• src/services/AuthService.ts — 10+ console statements
• src/popup/popup.tsx — 10+ console statements

Example (service-worker.ts):

console.log('Message received:', message.type, message.payload);
console.error('Screenshot capture error:', error);

No log levels, no timestamps, no context enrichment, no filtering.

No error reporting service

• No Sentry, Bugsnag, or similar integration
• Extension errors are only visible in browser DevTools
• Users cannot easily share error context
• No automated alerting on error spikes

Missing performance metrics

No measurement of critical paths:

• Screenshot capture latency
• Watermark processing time
• Upload queue depth and processing speed
• API response times
• IndexedDB read/write latency
• Service worker wake-up time

No usage analytics

• Cannot measure feature adoption (visible capture vs selection mode vs Hunt Mode)
• No upload success/failure rate tracking
• No auth flow completion metrics

Proposed Implementation

1. Structured Logger Module (src/utils/logger.ts)

enum LogLevel { DEBUG, INFO, WARN, ERROR }

class Logger {
  constructor(private module: string) {}
  debug(msg: string, context?: Record<string, unknown>) { ... }
  info(msg: string, context?: Record<string, unknown>) { ... }
  warn(msg: string, context?: Record<string, unknown>) { ... }
  error(msg: string, error?: Error, context?: Record<string, unknown>) { ... }
}

• Configurable log level per environment (debug in dev, warn in prod)
• Context enrichment (module name, timestamp, session ID)
• Replace all 99 console.* calls

2. Error Reporting Integration

• Integrate lightweight error reporter (e.g., Sentry browser SDK or custom endpoint)
• Capture unhandled promise rejections in service worker
• Include breadcrumb trail of recent actions before error

3. Performance Timing

• Use performance.mark() / performance.measure() for critical paths
• Track: capture→watermark→store→upload pipeline latency
• Store metrics locally, optionally report to backend

4. Feature Usage Metrics (privacy-preserving)

• Count events locally: captures, uploads, auth events
• No PII collection
• Optional opt-in remote reporting

Impact

• Enables data-driven debugging of user-reported issues
• Provides visibility into upload reliability and performance
• Supports informed prioritization of performance improvements
• Essential foundation before scaling user base

Files to modify

• New: src/utils/logger.ts
• All files with console.* calls (~17 files)
• src/background/service-worker.ts (add unhandled rejection handler)
• package.json (add error reporting dependency if chosen)