gateway: ACME rotation does not deactivate the old account at the CA

Follow-up to #935.

`RotateAcmeCredentials` registers a replacement account and re-pins every ZT domain's CAA `accounturi` to it. The old ACME account remains valid at the CA.

## Impact

CAA pinning only prevents the old account from issuing for our domains as long as the attacker cannot alter DNS. If the rotation motive is key compromise and the attacker also controls (or races) DNS, the old account can still complete issuance — and CAA resolver caching leaves a window even after re-pinning. Rotation as shipped is an operational re-pin, not a compromise-response tool; #935 documents this but does not close the gap.

## Proposal

Deactivate the old account (RFC 8555 §7.3.6, `"status": "deactivated"`) after the new credentials are published and CAA re-pinning succeeds:

- best-effort with a warning on failure, since the old credential may already be unusable (that is one reason to rotate);
- requires loading the old credential before overwriting it in KV, so the deactivation step must be sequenced into `do_rotate_acme_credentials`;
- check what `instant-acme` exposes for account deactivation.

Start with do_rotate_acme_credentials and the RotateAcmeCredentials flow, then check what instant-acme exposes for RFC 8555 account deactivation. Preserve the old credential before overwriting it in KV, publish the replacement credentials and CAA pinning first, and make old-account deactivation best-effort with a warning. Done means the old account is deactivated when possible without failing rotation when it is already unusable.

Written by the indexing model from the issue text.