Users still see a github.io URL: pick a langtech.cloud name for the instructions site

The whole point of the new site is that a field user never meets GitHub, and the link we hand them is currently https://sillsdev.github.io/langtechdepot/. It works, but the name still says GitHub.

Two routes, and the choice decides the work:

A. Custom domain now — add a docs/CNAME file containing e.g. get.langtech.cloud, point that name at GitHub Pages by DNS, and enable it in Settings → Pages. Cheap, reversible, and leaves the hosting where it is. The site keeps deploying itself on every push.

B. Serve it from depot.langtech.cloud directly — the end state, tracked separately in #14. More moving parts, and it means the site stops being self-deploying unless something copies the built tree to the box.

A does not block B: doing A now and B later costs one redirect.

Whichever is chosen, the site needs no edits. Every internal link is relative and the one absolute URL — the curl command on the Linux page — rewrites itself from window.location. The things that name the old URL and would need updating are:

• SITE_URL in /etc/langtechdepot/register.env on the server (see #12)
• $HelpUrl in client/setup-langtechdepot.ps1 and HELP_URL in client/install-langtechdepot.sh
• SITE_DEFAULT in docs/assets/site.js (the no-JavaScript fallback for the curl command)
• client/START-HERE.txt, which rides inside the Windows zip
• the README's first line

Start by comparing the two hosting routes described in the issue, then inspect docs/CNAME and the URL references in /etc/langtechdepot/register.env, client/setup-langtechdepot.ps1, client/install-langtechdepot.sh, docs/assets/site.js, client/START-HERE.txt, and the README. Confirm the selected domain works for the instructions site and that all listed old-URL references are updated without breaking deployment or relative links.