[Tong-bit-art]

Problem

The automation scan in #4410 found a timer-ownership bug in WorkerDaemon:

• setWorkerEnabled(type, true) called scheduleWorker() even when a timer for that type already existed.
• this.timers keeps only one handle per type, so the previous timeout leaked.
• The leaked timer survived stop() because stop() only clears handles currently in the map.
• setWorkerEnabled(type, false) removed the current timer but left the type in pendingWorkers, so a deferred run could still execute.
• A run already in flight rescheduled itself after completion even if the worker had been disabled meanwhile.

Net effect: a redundant enable can produce two concurrent runs of one worker type, and a disabled/stopped worker can fire once more untracked.

Change

• scheduleWorker() clears and removes any existing timer for the type before scheduling a new one.
• setWorkerEnabled(true) does nothing when a live timer or an in-flight run already owns that type.
• setWorkerEnabled(false) also removes the type from pendingWorkers.
• The post-run reschedule is gated on this.running && workerConfig.enabled, so disabling during a run cannot resurrect it.

Tests

New worker-daemon-duplicate-timers-4410.test.ts uses fake timers:

• three consecutive setWorkerEnabled('map', true) calls leave 1 pending timer;
• disabling a queued worker removes it from pendingWorkers.

Baseline (source stashed, --no-cache): both tests fail — 3 timers after three enables, and the disabled worker remains queued. Candidate: 2/2 passed.

No changes to worker intervals, scheduling order, or worker business logic.

Compatibility

• Repeated enable is now idempotent instead of creating duplicate timer chains.
• A worker that is already running or scheduled keeps its existing run; disabling cancels future runs.
• No public API change.