fix(ingress): give wildcard certificates their own certbot lineage

[kvinwang]

Why

With both x.com and *.x.com in DOMAINS, certbot names the lineages x.com and x.com-0001 (in issuance order), but certman._lineage_name mapped both names to x.com. One of them was served the other's certificate, the evidence attested the wrong certificate, and renew --cert-name targeted the wrong lineage.

What

• _lineage_name finds the lineage whose certificate holds exactly the domain, among <base>, <base>-NNNN and _wildcard.<base>[-NNNN]. Lineages certbot named itself keep working as they are: no rename, no re-issuance.
• A new lineage gets an explicit name: _wildcard.x.com for a wildcard (an underscore cannot appear in a certificate host name, so it never collides with a domain), the domain otherwise, with -NNNN appended if another certificate already holds that name (e.g. a wildcard-only deployment that later adds the base).
• certonly passes it as --cert-name unless it is a --csr issuance, which keeps no lineage.
• The 2.4–2.6 live/ cleanup (fix(ingress): keep deterministic TLS keys across renewals #132) looks under the bare name, where those versions put a wildcard's files.
• Tests point LETSENCRYPT_DIR at a temp tree.

On an upgrade that needs no issuance, haproxy serves the right certificates at once; /evidences is republished at start with #138, otherwise at the next renewal.

Tested against Pebble with ghcr.io/dstack-tee/dstack-ingress:2.6 and these scripts mounted, 3 passes each:

• Fresh apex + wildcard: lineages x and _wildcard.x, each SNI served its own certificate, then no-ops.
• Self-named lineages from 2.6/plain certbot, both orders (x=*.x, x-0001=x and the reverse): no issuance, no rename, each SNI served right; forced renewal renews the right lineage in place.
• Wildcard-only state, then base added: base issued into x-0001, wildcard untouched.
• State left by main where the apex was served the wildcard certificate: apex issued once into x-0001, both served right.
• DETERMINISTIC_TLS_KEY=true, fresh and from the 2.4–2.6 layout with the wildcard under the bare name: each served its own derived key, at most one issuance per name.
• CA switch on the self-named state: both replaced in their existing lineages.
• DELEGATION_ZONE: generated commands only.