feat(validator): use manual transaction encryption key rotation

[huitseeker]

Changes transaction encryption key rotation from automatic to manual. Operators configure a previous key, a current key, and an optional next key when each validator starts. Keys activate only at epoch boundaries, which supports repeated planned rotations with a one-epoch grace period.

• Validators sign the current key and optional next key as one schedule. The signature covers the network, activation blocks, and signing epoch. Clients reject stale or changed schedules.
• Key providers own opaque key IDs and secret keys. They enforce premature, current, grace, expired, and unknown key rules. Expired previous keys can be removed after the grace period.
• This removes automatic key derivation, the rotation worker, secret key export, and the SQLite key archive.

Schedule refreshes share one task, have fixed timeouts, and back off after errors or panics w/o treating cancellation as failure.

[juan518munoz]

Looks good, thanks! Left some minor comments.

[igamigo]

nit: I think "must restart at a rotation boundary" can be a bit ambiguous here - I'd say that the restarts must happen when changing the configured keys, and that keys automatically activate at epoch boundaries

[huitseeker]

Reworded. Restarts happen when the configured keys change; activation happens at epoch boundaries

[igamigo]

Is there a race from reading this snapshot outside the loop? By the time the mutex gets acquired another request could move the cache to the new attestation (then for the first request, cached.attested.epoch == epoch would fail and the cache would get rolled back).
If this could even happen it still seems like it would be a very low impact (if any) problem, as it would fail for a single request at most.

[huitseeker]

Yes, this race was possible. The tip is now read under the cache lock, with a regression test for this ordering