fix(zetaclient): keep signing when the keygen record is reset (backport v37)

[kingpinXD]

Backport of #4618 to release/zetaclient/v37. Do not merge before #4618.

Summary

• Whitelist p2p peers from TSS.TssParticipantList rather than the keygen record, which zetacore erases on any observer set change.
• Skip the keygen ceremony when a TSS already exists, instead of waiting on a record scheduled for a block that never arrives.
• Delete the keygen watcher that restarted every signer at once.
• Retry every zetacore query on the startup path with a constant backoff, so a contended RPC during a mass restart does not kill startup.

Scope

Production code only, matching the drain backports (#4614 / #4615). Five files: zetaclient/tss/setup.go, service.go, zetaclient/maintenance/tss_listener.go and the two test files. The e2e harness, CI wiring and changelog stay on main — they conflict on this branch and carry no runtime behaviour.

Compatibility with the drain

No shared files, and no drain code reads the keygen record. Setup runs before startDrainIfArmed in cmd/zetaclientd/start.go, so a signer that died in Setup never reached the drain at all — this fix is a prerequisite for the drain rather than a conflict.

Verified on this branch: build clean, zetaclient/tss and zetaclient/maintenance green, and the drain suites still green under -tags drain.

For operators

While a finalized TSS exists, a keygen scheduled via MsgUpdateKeygen will not run. Rotating requires removing the current TSS first. Tracked in #4623.

Greptile Summary

The PR keeps signers operational after keygen records are reset by deriving peer authorization from the finalized TSS and skipping unnecessary key generation. It also removes keygen-triggered restarts and adds retries around startup queries.

• Uses finalized TSS participants as the signing peer whitelist, with keygen grantees retained for first-key and legacy fallback cases.
• Removes keygen-record restart monitoring while preserving restart triggers for TSS address and history changes.
• Adds constant-backoff retries for keygen, current-TSS, history, and metrics startup queries.
• Adds focused tests for reset keygen records, whitelist selection, and listener behavior.

Confidence Score: 4/5

The PR should not merge until a terminal current-TSS query failure can no longer send a signer with an existing finalized key into the pending keygen path.

The new fallback conflates an unavailable GetTSS response with confirmed absence, so a restart during a scheduled rotation can block signing startup despite a usable finalized TSS.

Files Needing Attention: zetaclient/tss/setup.go

Important Files Changed

Filename	Overview
zetaclient/tss/setup.go	Reworks whitelist and ceremony selection around finalized TSS state, but terminal GetTSS errors can incorrectly route an existing signer into key generation.
zetaclient/tss/service.go	Adds the same startup retry policy to the metrics keygen query without an independently actionable defect.
zetaclient/maintenance/tss_listener.go	Removes keygen-record restart monitoring while retaining TSS address and history watchers as explicitly intended.
zetaclient/tss/setup_test.go	Covers reset, finalized, fallback, and invalid-key cases, but does not cover a terminal GetTSS failure while a finalized TSS coexists with a pending populated rotation record.
zetaclient/maintenance/tss_listener_test.go	Verifies keygen records are ignored and both retained TSS restart triggers still fire.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[Zetaclient Setup] --> B[Retry GetKeyGen]
  B --> C[Retry GetTSS]
  C -->|Finalized TSS returned| D[Whitelist TSS participants]
  C -->|No TSS| E[Whitelist keygen grantees]
  C -->|Terminal query error| F[Clear current TSS and fall back]
  D --> G[Skip KeygenCeremony]
  E --> H[Run KeygenCeremony]
  F --> H
  G --> I[Start signing service]
  H --> I

Loading

Prompt To Fix All With AI

### Issue 1
zetaclient/tss/setup.go:244-247
**Query failure hides finalized TSS**

When a signer with an existing finalized TSS restarts after `MsgUpdateKeygen` has created a populated pending record and `GetTSS` returns a terminal query error, this branch replaces the unknown result with an empty TSS. `Setup` then invokes `KeygenCeremony` and waits for the scheduled block or finalization instead of starting with the usable key, preventing signing startup during the query failure.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

_{Reviews (1): Last reviewed commit: "fix(zetaclient): keep signing when the k..." | Re-trigger Greptile}

Greptile also left 1 inline comment on this PR.

[ws4charlie]

LGTM — diffed this against #4618 and all five files are byte-identical, and the pre-patch baselines match across main/v37/v38 so the cherry-pick is clean. Built it and ran the tss + maintenance unit tests locally, both green.

[codecov]

Codecov Report

❌ Patch coverage is 77.55102% with 11 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
zetaclient/tss/setup.go	80.85%	9 Missing ⚠️
zetaclient/tss/service.go	0.00%	2 Missing ⚠️

📢 Thoughts on this report? Let us know!