Audit PostHog + Sentry overlap

# PostHog + Sentry Overlap

Both tools are wired in; their boundary was never explicitly designed. With Sentry trimmed to errors-only, worth deciding what each tool is *for*.

## Where they overlap (observed)

- `services/product.js#identify()` fans the same user payload out to **three** tools — PostHog, Sentry (`setUser`), and HubSpot (`_hsq`). One function, three destinations, drift-prone.
- `Sentry.setUser` lives in `services/product.js` (a file named for analytics), separate from `services/error-tracking.js` where the rest of Sentry lives.
- Localhost filtering is inconsistent: Sentry has a SDK-level `beforeSend` localhost guard; PostHog has none.
- PostHog ships its own Errors product; we don't use it. Sentry's Errors is the system of record.

## Questions

- Sentry-for-errors + PostHog-for-everything-else — right split, or accidental?
- Should `Sentry.setUser` move out of `services/product.js` into `services/error-tracking.js`?
- One `identify(user)` entry point that fans out, or keep explicit per-tool wiring?
- Is `posthog-node` (backend) actually used? For what?
- Who opens each tool's dashboard, and where do alerts land?

## Note from eng meeting 7/20

It must be able to trace spans across a WebSocket → MQTT boundary. We don't trace anything touching the broker today, and that path is central to where the platform is going.