fix(dkg): restart decrypt worker whenever an active round exists

[0xHansLee]

Problem

The TDH2 decrypt worker was only (re)started for the latest round. If a node restarted while the next round had already opened registration (latest round != active round), no start path fired: ResumeDKGService's recovery branch gates on the latest round's stage being Active, which it isn't once the next round opened. Decrypt requests then queued indefinitely until the next round activated — days on Aeneid. This took Aeneid CDR decryption fully down after the geth v1.2.2 upgrade restart.

Fix

In ResumeDKGService, (re)start the idempotent worker whenever an active DKG round exists, independent of the latest round's stage. LatestActiveRound is written only on the finalize success path, so it stays intact across the next round's churn and across restarts.

Tests

• TestResumeDKGService_ActiveRoundStartsWorker
• TestResumeDKGService_NoActiveRoundNoWorker
• TestResumeDKGService_CompletedActiveStartsWorker

issue: #854

[yingyangxu2026]

Verified the fix on a devnet: restarting story in the window where the next round has opened registration while an active round still serves (latest != active) now brings the decrypt worker back up ("Decrypt worker started" + the worker picks up the active round's queue), which the old stage-gated path skipped. One remaining gap in the same failure family:

The worker has no deadline anywhere downstream. workerCtx is context.Background() (dkg_svc.go:295), passed straight into client.PartialDecryptTDH2 (:632), and kernel_client.go:59 dials with only transport creds — no per-call timeout, no keepalive. If the kernel wedges (accepts the connection but never responds), the worker's synchronous loop blocks indefinitely and never panics, so the decryptWorkerRunning flag is never reset and ResumeDKGService's CompareAndSwap keeps failing — the worker stays dead with no self-heal, the same end state as #854. Suggest a per-call timeout context plus gRPC keepalive dial params (and/or a watchdog that resets the flag on a stalled tick).

Also, when there's no active round (worker not started, :107) or the CompareAndSwap no-ops because the worker is already running (:289-291), nothing is logged, so a healthy-but-idle worker can't be told apart from a stuck flag over a dead goroutine. A Debug line at each would help (Info would be too noisy given it runs every block).