fix(webapp): wrap sentry tenant processor registration in singleton()

Remix's dev mode re-evaluates the entry module on code changes, but
`@sentry/remix` lives in node_modules and isn't reloaded — so without a
singleton guard each HMR reload was appending another copy of the
processor to Sentry's global processor list. Idempotent at runtime
(the processor is a pure read+stamp), but the list grew unbounded over
a dev session. Matches the pattern used by the two adjacent
`singleton()` calls.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Author: d-cs

apps/webapp/app/entry.server.tsx

@@ -291,9 +291,16 @@ process.on("uncaughtException", (error, origin) => {
 singleton("RunEngineEventBusHandlers", registerRunEngineEventBusHandlers);
 singleton("SetupBatchQueueCallbacks", setupBatchQueueCallbacks);
 
-if (env.SENTRY_DSN) {
-  Sentry.addEventProcessor(addTenantContextToEvent);
-}
+// Wrapped in singleton() so Remix's dev-mode CJS reloads don't append
+// duplicate copies of the processor — Sentry's processor list lives in
+// node_modules and persists across module reloads. Idempotent at runtime
+// (the processor is a pure read+stamp), but the pattern matches the rest
+// of this file.
+singleton("SentryTenantContextProcessor", () => {
+  if (env.SENTRY_DSN) {
+    Sentry.addEventProcessor(addTenantContextToEvent);
+  }
+});
 
 export { apiRateLimiter } from "./services/apiRateLimit.server";
 export { engineRateLimiter } from "./services/engineRateLimit.server";