Custom subdomains pin reliably at publish

Asking for a custom subdomain while publishing a cloud app now reliably gives your site that address.

• The address you ask for is the address you get. A publish that requests a subdomain (in chat, the publish dialog, the API, or the CLI) now pins it the moment the publish succeeds, and the reported site URL uses it. Before, the request could be silently lost and the site answered only at its generated address.
• You learn the outcome, not a promise. The publish result now states whether the subdomain was pinned, or exactly why it was refused - for example when the name is already taken.
• Bad names are refused up front. A subdomain that is malformed, reserved, or already in use is refused before the publish starts, so you never wait through a deploy to learn the name cannot work.
• Changing the address of an already-published app no longer requires a re-publish from the API or the agent - the same subdomain controls the editor always had are now available everywhere.