gateway: no automatic CAA reconciliation loop

Follow-up to #935.

Two paths currently rely on an operator manually rerunning `SetCaa` to converge:

1. **Partial rotation failure** — `RotateAcmeCredentials` publishes the new credentials first, then re-pins CAA best-effort per domain. Domains that fail stay pinned to the old account until `SetCaa` is rerun; issuance for them fails CAA while existing certs keep serving, so the breakage can stay invisible for up to ~90 days.
2. **Domain-list skew** — rotation and `SetCaa` iterate the local WaveKV snapshot. A ZT domain added on another node but not yet synced is silently skipped and stays pinned to the old account.

Certificate renewal has a periodic task that retries until it converges; CAA has no equivalent.

## Proposal

Add a periodic reconciliation pass (piggybacking on the existing renewal loop) that:

- reads the published credential's `accounturi`;
- for each ZT domain, checks whether the CAA `issue`/`issuewild` records pin that URI (DNS read only in the common case);
- re-pins divergent domains via the existing `set_caa` path, logging loudly.

This removes both manual steps, converges the concurrent-rotation aftermath (#1008), and also cleans up leftover `;` guard records from an interrupted `set_caa_records` run. Cost is N DNS reads per interval — quantify, but at renewal-loop frequency this is negligible.

Trace RotateAcmeCredentials, SetCaa, set_caa, set_caa_records, and the existing certificate-renewal periodic task. Start by understanding how published accounturi values and ZT domains are obtained, then verify that reconciliation checks CAA records and retries divergent domains. Done means partial rotations, domain-list skew, and leftover guard records converge without manual SetCaa reruns, with the DNS-read cost quantified.

Rédigé par le modèle d'indexation à partir du texte de l'issue.