18. Deploying: by moving a name

• ucm build <app> writes an immutable, content-addressed build to .ucm/apps/<app hash>/. Its assets are served under /_app/<hash>/. An existing build is reused unless --force.
• ucm start <app> serves the build the app's name points to now. When the name moves (ucm update, mv, reset, pull), it builds the new version if needed and switches to it. Deploying and rolling back are both moving a name, like Unison's service names pointing at service hashes. It also runs the job worker and schedules, and serves HTTP routes with --http.
• There is no version skew. Earlier builds stay served, and their server functions stay callable. A tab opened before a deploy keeps loading its own assets and calling the exact code it was built against, until it reloads. prod.test.ts deploys v2 and checks the v1 tab still works, then rolls back.
• ucm apps lists builds; ucm apps prune --keep N removes old ones. It keeps the current build plus the N newest others; ucm start --keep N does this after every deploy. A tab still on a pruned build gets 410 Gone from its next server call, and the browser runtime reloads the page onto the current version.
• Pushing is deploying. ucm push prod to a server running ucm start sends only the definitions it lacks. The server verifies them by re-hashing, then its ucm start sees the name move, builds and switches. There's no deploy script and no restart.
• TLS. ucm start --tls serves HTTPS; cookies then default to Secure.
• Errors. Unexpected errors are logged on the server and reach the browser only as "internal error" (server API).
• Data changes are covered in data: old pages that read rows written by newer code get a 410 and reload.

built from 5890e54f