App ingress issues a per-deployment certificate instead of using a wildcard for the apps domain

[v0l]

build_ingress annotates every deployment's Ingress with cert-manager.io/cluster-issuer and requests a per-deployment app-tls secret in its own namespace (lnvps_operator/src/app_deployments.rs:902-934), so each app triggers a fresh HTTP-01 issuance for its own <name>.<region>.apps.lnvps.cloud host.

That spends one of Let's Encrypt's 50 certificates per registered domain per week — global across lnvps.cloud, refilling at one per 202 minutes, renewals included, with certificate lifetimes dropping to 64 then 45 days. Issuance also sits on the critical path of a customer's first load. #252 already stopped never-paid deployments from provisioning, so this is a real-customer growth ceiling rather than an order-spam one.

Approach

The default host reuses a shared wildcard TLS secret. The controller's --default-ssl-certificate is not an option — the secret is referenced per ingress.

• Operator: app-tls becomes a configured shared secret name for the default host, issuer annotation dropped for that host only (lnvps_operator/src/app_deployments.rs:846,873). Custom domains untouched at :882 and keep their own issuance. Config flag plus unit tests.
• Distribution: reflector. Annotate the wildcard secret in cert-manager's namespace, mirror to app-.*. Operator RBAC is unchanged, so Operator: scope secret access to the app-N namespaces it creates #299's boundary stays as shipped. Cost is one more cluster component and a mirroring lag on a fresh namespace.
• Rejected — operator copy: cert-manager reissues the wildcard every ~45-64 days, so a copy at namespace create ships an expiring cert. Keeping it fresh means re-reading a private key across namespaces on every reconcile, which is exactly what Operator: scope secret access to the app-N namespaces it creates #299 removed.

Cluster side: deploy the reflector, issue the wildcard through the existing DNS-01 issuer, annotate it.