fix(service): tolerate light-client lag when reading the round's DKG network

[0xHansLee]

Problem

GenerateAndSealKey reads the round's DKGNetwork once at the light client's verified head and returns codes.Internal on any error, so a transient not-found read at a round boundary (verified head still below the round's start block) hard-fails registration — and the consensus client's ~6s retry window cannot outlast the ~40s observed lag. The dealing/finalization paths (GetOrLoadRoundContext, waitForFinalizationRegistrations) already tolerate lag-shaped reads (threshold == 0, earlier stage) but fail fast on the same not-found shape.

Fix

• GetDKGNetwork wraps a new sentinel story.ErrDKGNetworkNotFound on an empty read (message text unchanged).
• GenerateAndSealKey fetches the network via waitForDKGNetworkCreation: a bounded retry (30 × 3s, outlasting the ~40s boundary lag with margin) scoped to the sentinel — any other error still fails fast. Exhaustion returns the existing ErrLightClientLag sentinel mapped to codes.Unavailable; the loop honors ctx cancellation so a disconnected caller gets codes.Canceled immediately instead of the handler burning the budget. Retries log at Debug within the documented normal lag and escalate to Warn beyond it.
• fetchRoundContext classifies the not-found read as ErrLightClientLag so GetOrLoadRoundContext's existing retry covers it, and waitForFinalizationRegistrations retries it like an earlier-stage read.

Test coverage

Symbol	Coverage
waitForDKGNetworkCreation	93.8%
waitForFinalizationRegistrations	100%
GetOrLoadRoundContext / fetchRoundContext	81.0% / 85.7%

issue: #96

[jinn-agent]

The retry logic and sentinel-error design are solid, and the test coverage is thorough. One build-breaking issue found: dkg_finalize.go and dkg_generate_key.go both import "github.com/pkg/errors" as errors, then call errors.Is(...) — a function that does not exist in github.com/pkg/errors (it only makes its own types implement Unwrap so the standard library's errors.Is can operate on them). This will produce a compile-time undefined: errors.Is error and prevent the binary from building. The fix is to add a blank-aliased standard library import (stderrors "errors") and call stderrors.Is, or to switch the existing pkg/errors import to an alias so the standard errors identifier is available. round_context.go already imports standard "errors" and is unaffected.

---

Review iteration 2 · Commit f24a3e2 · 2026-08-04T03:30:30Z

[jinn-agent]

Found 2 critical issue(s) that need attention.