[Feature]: Support wildcard application domains with Traefik HostRegexp and DNS-01

Description

Add first-class support for wildcard application domains such as https://*.example.com.

This is separate from #11641. That bug concerns an existing wildcard domain preventing unrelated fields on the General page from being saved. Preserving a legacy wildcard value does not mean Coolify currently supports generating correct wildcard routing and certificates.

Current behavior

Coolify's Traefik label generation uses a literal host matcher:

Host(`*.example.com`)

Traefik wildcard routing should instead use a safely generated HostRegexp rule. Coolify also currently rejects new wildcard application domains through shared validation and API tests.

Wildcard TLS certificates require an ACME DNS-01 challenge. HTTP-01 and TLS-ALPN-01 cannot issue wildcard certificates.

Proposed behavior

When an application uses a wildcard domain and its destination uses Traefik:

1. Accept only a wildcard that occupies the complete leftmost DNS label, for example https://*.example.com.
2. Generate a safe Traefik HostRegexp matcher for exactly one subdomain label.
3. Escape the base domain rather than placing user-controlled input directly into a regular expression.
4. Generate or associate explicit TLS domain configuration for *.example.com and, when requested separately, example.com.
5. Require a certificate resolver configured for DNS-01, or show a clear validation error explaining why automatic wildcard certificate issuance is unavailable.
6. Keep ordinary domains on the existing Host() path.

Validation constraints

Accept:

https://*.example.com

Reject examples such as:

https://foo*.example.com
https://foo.*.example.com
https://*.*.example.com
https://*.com
https://*

An asterisk must not be treated as arbitrary regular-expression input.

Proxy compatibility

Wildcard support should be capability-aware. The implementation must define behavior for:

• Traefik versions and rule syntax supported by Coolify;
• Caddy destinations;
• destinations with proxy type NONE;
• custom certificates or custom certificate resolvers;
• existing installations that already contain legacy wildcard values.

If the first implementation is Traefik-only, the UI and API should reject wildcard creation for unsupported proxy types with a specific message.

Acceptance criteria

• A request for tenant.example.com routes to an application configured with https://*.example.com.
• The wildcard matches one label and does not unintentionally match example.com or a.b.example.com.
• The apex domain can be configured separately.
• Certificate generation works with a configured DNS-01 resolver.
• Missing DNS-01 support produces an actionable error rather than a broken deployment.
• Generated router rules never interpolate unescaped user input as a regular expression.
• UI, API, application, Compose-service, and preview-domain behavior are consistent.
• Tests cover label generation, TLS domain configuration, accepted and rejected wildcard forms, proxy capability checks, and legacy stored values.

Related issue

• #11641

Begin by locating the shared wildcard-domain validation and Traefik label generation, then trace how UI, API, application, Compose-service, and preview-domain paths configure domains and certificates. Review the existing proxy and certificate-resolver handling before defining behavior for unsupported destinations and legacy values. Done means the requested routing, DNS-01 validation, escaping, capability checks, and accepted/rejected wildcard cases are covered by tests across those paths.