fix(ingress): keep deterministic TLS keys across renewals

[kvinwang]

DETERMINISTIC_TLS_KEY only survived until the first renewal, so a pinned SPKI broke or the certificate expired:

• dns-01: certbot --csr keeps no lineage, so certbot renew never renewed the certificate, and re-issuing failed because certbot won't overwrite --cert-path.
• tls-alpn-01: lego ignored the setting and generated a new key on every renewal.
• DELEGATION_ZONE: the CSR was never passed to certbot, and the key file pushed the lineage to <name>-0001.
• Existing deployments: turning the flag on had no effect; the old, randomly keyed lineage kept being renewed.

Changes:

• dns-01: certificates for derived keys live in /etc/letsencrypt/deterministic/<name>/ (_wildcard.<base>/ for a wildcard, so an apex and its wildcard don't share one). certman renews them at certbot's thresholds (2/3 of the lifetime, or RENEW_DAYS_BEFORE), and re-issues whenever the served certificate doesn't carry the derived key.
• tls-alpn-01: uses lego run --csr --private-key, so lego's own renewal logic (including ARI) still decides when to renew. --renew-force is used when the key differs, and .key is kept in sync.
• Upgrades from 2.4–2.6: those releases wrote plain files into live/<name>/ with no renewal config, and 2.6 wrote privkey.pem before issuing, so a failed issuance (and the first pass of every 2.6 DELEGATION_ZONE deployment with the flag on) left only that file. From the second pass on, 2.6 under DELEGATION_ZONE also left a real certbot <name>-0001 lineage; fix(ingress): give wildcard certificates their own certbot lineage #142 migrates that. Since certbot only ever puts symlinks there, certman now treats a plain privkey.pem as that old output. 2.4–2.6 put a wildcard's there under the base name too. If the flag is on, a plain fullchain.pem is there too, its key matches, and the deterministic directory for the name on the certificate is empty, it moves the files there. Otherwise it removes them, so certbot can create the lineage when the flag is off. An empty renewal/<name>.conf left by certbot failing over those files is removed as well; it would otherwise push the lineage to <name>-0001.
• The CSR now has a SAN. The README documents when the SPKI changes (new app ID, different KMS, no KMS).

Tested locally against Pebble (PEBBLE_VA_ALWAYS_VALID=1) with a fake GetKey socket, running the 2.6 image with these scripts mounted:

• certbot: fresh issuance, a steady pass, forced renewal (same SPKI, new serial), toggle-on over an existing lineage, wildcard, and a KMS key change.
• lego: the same cases.
• Upgrade from the 2.4–2.6 layout (plain files in live/<name>/, no renewal config): flag turned off, then on, and on, then off, with 3 passes each. No -0001 lineage appears, and after the first pass each later pass is a no-op.
• Failed 2.6 layout (only a plain privkey.pem in live/<name>/, with and without an empty renewal config) and the full layout with a leftover empty renewal config, flag off and on, 3 passes each: no -0001, one issuance (or adoption) and then no-ops.
• lego: --private-key alone would be enough for the first issuance, but lego 5.3.1 ignores it on renewal, even with --renew-force, and generates a new key. That is why the CSR is kept.
• Delegation: checked the generated command only.
• Apex and wildcard together (both orders) from the 2.6 layout, flag on: each serves its own derived-key certificate; one issuance each, then no-ops.

All passed.