fix: register operations in worker threads so replication WS can dispatch them

After 40600bf moved the HTTP operations API to the main thread only,
`server.registerOperation` was no longer wired up in worker threads. Plugins
that call `server.registerOperation?.({...})` at module load time (e.g.
replication's setNode.ts, clusterStatus.ts) silently no-op'd in workers
because the optional-chain short-circuits when the method is undefined.

This breaks inter-node replication setup: `add_node` opens a WebSocket to the
target node's replication port (9933) and sends `add_node_back`. The WS
handler runs in a worker thread and dispatches via `server.operation()`, which
looks up in the operation function map. Since `add_node_back` was never
registered in the worker, every cluster setup attempt fails with:

  "Operation 'add_node_back' not found and connection was required to sign
  certificate"

This blocks `fullyConnectedReplication.test.mjs`, `replicationLoad.test.mjs`,
and anything else that exercises multi-node clustering.

Fix: in worker threads, eagerly require `serverHelpers/serverUtilities`
directly, which installs `server.operation`, `server.registerOperation`, and
initializes the operation function map without binding the fastify HTTP layer
(that stays main-thread-only per the original change).

Verified by re-running `fullyConnectedReplication.test.mjs` — 12/12 pass
(6 RocksDB + 6 LMDB). `replicationLoad.test.mjs` `connect nodes` and
`Deploy app and test replication` now pass; remaining failures
(`replicate across many databases`, `replicate insert/upsert across all nodes`)
are unrelated concurrency / many-database issues.

Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>

Author: kriszyp

components/componentLoader.ts

@@ -116,6 +116,16 @@ export const TRUSTED_RESOURCE_PLUGINS = {
 };
 if (isMainThread) {
 	TRUSTED_RESOURCE_PLUGINS.operationsApi = require('../server/operationsServer');
+} else {
+	// The HTTP operations API itself only binds in the main thread, but worker threads still
+	// dispatch operations — most notably, the replication WebSocket handler in workers receives
+	// inter-node operations like `add_node_back` and calls `server.operation(...)`. That requires
+	// `server.operation` / `server.registerOperation` to be wired up here too, and the operation
+	// function map to be initialized, BEFORE component plugins (replication, etc.) load and call
+	// `server.registerOperation?.({...})` at their module top level. Requiring serverUtilities
+	// directly (rather than the full operationsServer) avoids binding the fastify HTTP layer in
+	// workers while still installing the dispatch machinery.
+	require('../server/serverHelpers/serverUtilities');
 }
 
 for (const { name, packageIdentifier } of getEnvBuiltInComponents()) {