node:worker_threads: per-thread --use-system-ca, real eventLoopUtilization, --cpu-prof in workers, node's online timing, error.code / stack-getter / timeOrigin fixes, async_hooks WORKER resource, worker_threads dc channel (+10 upstream tests) - #34424

The async_hooks `WORKER` init and the `worker_threads` diagnostics_channel publish fire in the opposite order to Node — Node emits the async_hooks init first (synchronously from AsyncWrap's constructor when `this[kHandle] = new WorkerImpl(...)` runs mid-constructor), then does the dc publish at the very end. Swapping these two blocks so `this.#emitAsyncHooksInit()` runs before `workerThreadsChannel.publish(...)` would match Node exactly.

`#hasRef` is unconditionally initialized to `true`, but the native WebWorker constructor honours Bun's `options.ref` (JSWorker.cpp:191-195), and this constructor spreads user options through — so `new Worker(f, { eval: true, ref: false })` starts unref'd on the event loop while the async_hooks WORKER resource's `hasRef()` reports `true`. Nit only (`ref` is a Bun-only extension), but the initializer could read `options?.ref !== false` to keep the stated "mirrors ref()/unref()" invariant.

nit: the sibling header comment in `src/js/internal/async_hooks_tick.ts` (lines 9-11) still says "Currently only TickObject `init` events are delivered … promise, timer and native resource events are still unimplemented", which is now stale since `worker_threads.ts` dispatches WORKER init events into the same `tickInitHooks` array. Worth updating alongside this comment for consistency.