[Fix] Deployment accepts malformed domain names

[roomote-roomote]

​Opened on behalf of @daniel-lxs. Follow up by mentioning @roomote-roomote, in the web UI, or in Telegram.

What changed

• Reject deployment hostnames with empty labels, leading or trailing hyphens, labels longer than 63 characters, total names longer than 253 characters, or embedded newline/carriage-return characters.
• Validate managed DigitalOcean DNS zones with the same rules before invoking Terraform.
• Restructured the deployment validation test so it invokes the validator through explicit positional arguments to bash instead of interpolating a path into a -c shell string.
• Add focused boundary coverage, including a newline-embedded domain, to the existing deployment validation command.

Why this change was made

The deployment CLI previously accepted malformed values such as foo..example.com and foo-.example.com, so operators received a later Terraform or provider failure after provisioning work had already begun. A follow-up review found that the label-splitting read call also stopped at the first newline, letting a value like roomote.example.com\nnot-a-domain validate only its first line while an unvalidated remainder still reached generated Terraform/env values. A related CodeQL finding flagged the test harness for building a shell command from an uncontrolled path.

Impact

Invalid app, preview, and managed DNS zone names — including newline-smuggled values — now fail immediately with the existing invalid domain error, while valid single-label and multi-label names continue to work. The test harness no longer constructs a shell command string from the script path, clearing the CodeQL alert while keeping the same subprocess-boundary coverage.

[roomote-community]

No code issues found. See task

• deploy/scripts/lib.sh:53 accepts a domain with a newline because read validates only the first line.

_{Reviewed 1ad8d20}