feat(core): configurable WASM worker thread count via EndpointFactory setup()

[imaTik0]

AsyncEngine (C++):

• Add EM_JS readWorkerCountFromJs() that reads window.__privmxWorkerCount
• AsyncEngine() constructor reads the global and uses it as the thread-pool size (defaults to 4 when absent; enforces minimum of 2)

EndpointFactory (TypeScript):

• setup() now accepts string | EndpointSetupOptions (backwards-compatible; a plain string assetsBasePath is still accepted)
• New EndpointSetupOptions interface: { assetsBasePath?, workerCount? }
• When workerCount is provided, sets window.__privmxWorkerCount before calling endpointWasmModule() so the C++ constructor reads it during WASM initialisation on the worker thread

Tests (E2E):

• measureSendMessages() helper: reload page, call setup({ workerCount }), send N messages concurrently, return elapsed ms
• "Worker count / EndpointFactory.setup() initialises WASM with the requested worker count": runs at 2/4/8/16 workers, logs timings
• measureSignData() helper: same pattern using 200 concurrent signData calls (CPU-bound secp256k1, no network)
• "Worker count scales CPU-bound crypto throughput": hard-asserts that 4w < 2w and 8w < 4w to verify the parameter actually controls parallelism
• setup({ assetsBasePath }) object-form test: verifies connect + key derivation work end-to-end when using the new options object