fix(ingress): use gateway hostname for CNAME targets - #122

Summary

Use gateway.<gateway-base-domain> for the traffic CNAME target in the ingress examples, k3s template, and E2E default. Android's hostname-validating resolver rejects the standalone underscore label in the legacy _.<gateway-base-domain> CNAME target.

Inspection found that scripts/dns01.sh forwards GATEWAY_DOMAIN to both direct and delegated alias writes, and scripts/tlsalpn.sh / dnsguide.py forward it to manual/webhook DNS records. The target originates in the deployment configuration. This change updates those shipped inputs and their documentation while preserving explicit operator-provided targets and ACME/routing labels.

• Update single/multi-domain, provider, TLS-ALPN, and k3s examples consistently.
• Add regression tests that read the shipped Compose values and execute the E2E default assignment, then exercise DNS record construction for both challenge modes. Cover explicit custom/legacy overrides and preservation of _acme-challenge, _dstack-app-address, and CAA records.
• Run the new tests and existing DNS guide suite in the validation workflow.
• Document prerequisite gateway DNS publication, existing-record collision checks, delegation/flattening behavior, and staged legacy retention.

RFC rationale

• RFC 1034 §3.5
  gives the preferred hostname syntax: ASCII letters, digits, and hyphens,
  starting with a letter and ending with a letter or digit.
  RFC 1123 §2.1
  also permits a leading digit; underscores remain outside this hostname syntax.
• RFC 2181 §11
  permits arbitrary DNS labels within length limits, including underscores and
  CNAME values, and allows applications to impose their own restrictions.
  Thus _.<gateway-base-domain> is representable in DNS, while the platform's
  server target uses hostname-compatible gateway.<gateway-base-domain> for
  client interoperability. Protocol verification labels such as
  _acme-challenge and _dstack-app-address remain valid for their DNS uses.
• RFC 2181 §10.1
  permits only one canonical target per alias. During migration, atomically
  replace each traffic alias's CNAME target, keeping exactly one target at that
  owner. Retain old and new gateway address records under their separate names
  until existing consumers have migrated and their TTLs have elapsed.

Verification

• RED: the new regression suite failed on all three shipped underscore-target inputs before the change.
• GREEN: python -m pytest custom-domain/dstack-ingress/scripts/tests -q — 55 passed, 13 subtests passed.
• bash custom-domain/dstack-ingress/scripts/tests/test_sanitizers.sh — passed.
• bash -n custom-domain/dstack-ingress/scripts/tests/e2e-test.sh — passed.
• Docker Compose config --quiet for custom-domain/dstack-ingress/docker-compose.multi.yaml and k3s/docker-compose.yaml — passed (standalone Compose CLI; test domain inputs, no credentials or deployments).
• git diff --check — passed.
• ./dev.sh check-all was exercised but is not counted as a clean validation: it returns success while reporting errors; the local Docker CLI initially lacked its Compose plugin, optional linters were absent, and existing examples trigger privileged-container/socket security findings. The changed Compose files were independently validated with the standalone Compose CLI afterward.
• Live DNS/CA/CVM E2E and Android application checks were not run; these require a separately authorized rollout/test environment.

Rollout / compatibility

Publish and verify gateway.<gateway-base-domain> at the gateway zone first, with the same ingress addresses and a hostname-valid chain. Pointing it back to _.<gateway-base-domain> preserves the Android failure. Then update each deployment's GATEWAY_DOMAIN and reconcile its traffic CNAME, including delegation-zone aliases. Existing environment overrides remain unchanged; rebuilding the image alone does not migrate them. Keep legacy gateway records until all consumers have moved and DNS TTLs have elapsed. The guide's address-equivalence fallback makes full CNAME-chain inspection necessary during migration.

Scope is code, examples, tests, and documentation only. No production DNS changes, deployments, legacy deletions, or merge are performed by this PR.