feat(observability): add env-gated Sentry error tracking

[samxu01]

Closes #664

Summary

• initialize @sentry/node before all backend imports and attach its Express error handler only when SENTRY_DSN is present
• lazy-load an isolated @sentry/react chunk only when the compile-time frontend DSN is present
• disable default PII and trace sampling, and scrub user data, request headers, and cookies on both sides
• propagate release IDs and the frontend DSN through Docker/Actions; gate the backend DSN and ESO remoteRef behind errorTracking.enabled
• document Sentry project setup, secret ordering, ESO sync, alerts, privacy, rollback, and the inert self-hosted default

Verification

• backend: 167 suites / 1,219 tests passed on Node 20
• frontend: 50 suites / 216 tests passed on Node 20
• backend production TypeScript build passed
• frontend production builds passed with DSN absent and present; absent build had no Sentry chunk or ingest/envelope markers, enabled build emitted one isolated lazy Sentry chunk with the release
• changed-file ESLint passed with 0 errors
• Helm lint passed for base and dev values; disabled render contains no Sentry config, enabled render contains the gated optional DSN and release
• kubeconform: 35 resources valid, 0 invalid/errors/skipped
• real Chrome no-DSN check: /v2/landing rendered with HTTP 200, no console errors, and no Sentry/ingest/envelope resources or requests

Rollout note

Do not dispatch Deploy Dev until commonly-dev-sentry-dsn exists in GCP Secret Manager and DEV_SENTRY_FRONTEND_DSN exists in the GitHub dev environment. A missing remoteRef prevents the whole api-keys ExternalSecret from reconciling; the runbook preserves the required ordering.

[samxu01]

Review verdict: changes requested (submitted as comment — REQUEST_CHANGES 422s from this identity).

Reviewed against the #664 spec and REVIEW.md, with focus on the privacy gate. The gate itself is right on both sides: no DSN → Sentry.init never runs (unit-tested), the frontend chunk is dead-code-eliminated via the vite define, Helm defaults off with the ESO entry correctly values-gated, and the runbook covers ordering, spike alerts, and rollback. Lockfile adds resolve to registry.npmjs.org only.

Important — one change requested

• backend/instrument.ts beforeSend (and the identical scrub in frontend/src/sentry.ts): the scrub deletes user, request.headers, and request.cookies but keeps request.data and request.query_string. Sentry's Express request-data integration attaches the request body by default, so an unhandled error on POST /api/auth/* would ship the login body (email + password) to Sentry, and query strings can carry tokens. Add delete scrubbedEvent.request.data; and delete scrubbedEvent.request.query_string; to both scrubs, and extend the two "scrubs sensitive request data" tests to include data + query_string in the fixture and assert they're gone. The URL + method that remain are enough for debugging.

Everything else is approve-ready as-is; no other changes needed.

[lilyshen0722]

@samxu01 review fix pushed in 5d280418:

• both beforeSend scrubbers now delete request.data and request.query_string
• both privacy fixtures include a login-style body and token query string, with explicit removal assertions
• focused backend/frontend tests, both production builds, and changed-file ESLint pass

Ready for the fast re-review.

[samxu01]

Re-review verdict: APPROVE — ready to merge (submitted as comment; both APPROVE and REQUEST_CHANGES 422 from this bot identity on this PR).

Re-reviewed 5d280418: both beforeSend scrubbers now delete request.data and request.query_string in addition to user/headers/cookies, and both tests exercise a login-style body + token query with explicit removal assertions plus a strict toEqual on the surviving shape (url + method only). The privacy concern from my previous review is fully addressed; everything else is unchanged from the already-approve-ready state.

One non-blocking doc nit, fine in a follow-up: docs/runbooks/error-tracking.md §Privacy stance still says the scrub removes "the user object and all request headers and cookies" — it now also removes request bodies and query strings. Doc understates the protection (safe direction), but keep it accurate.