refactor(webapp): split mollifier drainer factory into create + start

initializeMollifierDrainer() no longer calls drainer.start() — it
returns a configured-but-stopped drainer. worker.server.ts init() now
invokes drainer.start() AFTER the SIGTERM/SIGINT handlers are
registered, gated on the same __mollifierShutdownRegistered__ guard so
dev hot-reloads can't double-start.

Closes the residual race window between drainer.start() (previously
fired inside the singleton factory) and process.once("SIGTERM",
stopDrainer) in worker.server.ts. With construction and starting
separated, a signal landing during boot can never find the polling
loop running without a graceful-stop path.

Author: d-cs

apps/webapp/app/v3/mollifier/mollifierDrainer.server.ts

@@ -83,10 +83,16 @@ function initializeMollifierDrainer(): MollifierDrainer<BufferedTriggerPayload>
     isRetryable: () => false,
   });
 
-  drainer.start();
   return drainer;
 }
 
+// Returns a configured-but-stopped drainer. Callers MUST register their
+// SIGTERM / SIGINT shutdown handlers before invoking `drainer.start()` —
+// see `apps/webapp/app/services/worker.server.ts`. Starting inside the
+// singleton factory would put the polling loop ahead of handler
+// registration, leaving a narrow window where a SIGTERM landing between
+// `start()` and `process.once("SIGTERM", ...)` would skip the graceful
+// stop. The split is intentional.
 export function getMollifierDrainer(): MollifierDrainer<BufferedTriggerPayload> | null {
   if (env.MOLLIFIER_ENABLED !== "1") return null;
   return singleton("mollifierDrainer", initializeMollifierDrainer);