Move partial-proof cache refresh off the synchronous membership update path

[chaitanyaprem]

Summary

Partial-proof cache refresh currently happens synchronously on membership updates. That is acceptable at low churn, but under bursts of staggered registrations/removals it can add avoidable latency and repeated work on the hot path.

Why this matters

• Partial-proof regeneration is not needed to apply the membership update itself.
• Recomputing immediately on every update can create jitter when the tree changes frequently.
• The expensive work should be prioritized around active senders and done outside the critical path where possible.

Suggested direction

• Debounce or batch cache refresh after a short delay.
• Move regeneration to a background task/job.
• Keep the current proof-generation fallback path for cache miss/staleness.
• Consider prioritizing refresh for active members first if the design later expands beyond a single local cache.

Reference

The motivation and tradeoffs are discussed in the original blog post: https://forum.research.logos.co/t/rln-partial-proofs-in-practice/686

Notes

This is intentionally deferred. The current synchronous approach is fine for now unless we see sudden churn in practice.