fix(webapp): don't let an unreachable run-ops shard crash webapp startup

The run-ops client factory eagerly $connects for warm-up, but only caught the
rejection under NODE_ENV=test — outside test an unreachable shard/run-ops DB at
boot surfaced as an unhandled promise rejection. Always catch and log instead;
Prisma reconnects lazily on first query, so one unreachable shard must not take
down startup. Scoped to the run-ops factory only; the control-plane/legacy
builders are unchanged, so the RUN_OPS_SHARDS-unset path stays byte-identical.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Author: d-cs

apps/webapp/app/db.server.ts

@@ -1124,12 +1124,13 @@ function buildRunOpsClient({
 
   client.$on("query", (log) => queryPerformanceMonitor.onQuery(role, log));
 
-  const connectPromise = client.$connect();
-  if (env.NODE_ENV === "test") {
-    connectPromise.catch((error) => {
-      logger.warn(`Failed to eagerly connect run-ops prisma client (${role})`, { error });
-    });
-  }
+  // Eager connect is a warm-up only — Prisma reconnects lazily on first query. ALWAYS catch the
+  // rejection (not just under NODE_ENV=test), so a shard/run-ops DB that is unreachable at boot
+  // logs a warning instead of surfacing as an unhandled promise rejection. One unreachable shard
+  // must not take down webapp startup.
+  client.$connect().catch((error) => {
+    logger.warn(`Failed to eagerly connect run-ops prisma client (${role})`, { error });
+  });
 
   console.log(`🔌 ${connectedLabel}`);