fix(namecheap): use full app domain for CNAME instead of underscore wildcard

[jameslbarnes]

Summary

Namecheap's DNS servers don't serve CNAME records pointing to underscore-prefixed domains (e.g., _.dstack-pha-prod9.phala.network). The record appears in the Namecheap API but isn't visible in public DNS queries.

This fix detects when DNS_PROVIDER=namecheap and GATEWAY_DOMAIN starts with an underscore, then substitutes the full app-specific domain instead:

Before	After
_.dstack-pha-prod9.phala.network	{app_id}-{port}.dstack-pha-prod9.phala.network

Both resolve to the same IP (66.220.6.109), and the TXT records handle app routing, so functionality is preserved.

The Bug

1. dstack-ingress sets CNAME via Namecheap API → API returns success ✓
2. Query Namecheap API for records → CNAME appears ✓
3. Query public DNS (nslookup, Google DoH) → CNAME not found ✗
4. TXT records created the same way → work fine ✓

The issue is specific to CNAME records with underscore-prefixed targets.

Test Plan

Tested with hermes.teleport.computer:

• Before fix: CNAME in Namecheap API ✓, but NOT in public DNS ✗
• After fix: CNAME visible in public DNS ✓, site loads with SSL ✓

# Verify DNS resolves
$ nslookup hermes.teleport.computer
Address: 66.220.6.109

# Verify site works
$ curl -I https://hermes.teleport.computer
HTTP/1.1 200 OK

Changes

• Modified set_alias_record() in scripts/entrypoint.sh
• Added Namecheap-specific workaround that uses full app domain when GATEWAY_DOMAIN starts with underscore
• Reuses existing logic for fetching app_id from dstack socket

[jameslbarnes]

Question: TEE Attestation Verification

One thing we wanted to confirm: does the attestation verification process check the CNAME value?

The Phala dashboard validation shows:

CNAME hermes.teleport.computer
Expected: _.dstack-pha-prod9.phala.network

With our fix, the CNAME points to {app_id}-{port}.dstack-pha-prod9.phala.network instead of the underscore wildcard. Both resolve to the same IP, and the TXT records (which contain the app_id:port for routing) are unchanged.

Questions:

1. Does attestation verification check that CNAME specifically points to _.dstack...?
2. If so, should the validation be updated to accept {app_id}-{port}.dstack... as equivalent?
3. Is there a security property that specifically requires the underscore wildcard?

The fix works for routing and SSL - just want to make sure it doesn't break attestation verification.