Add deployment tooling for a single production VPS

The repo had no infrastructure at all: no Dockerfile, no nginx config, no
systemd unit, no deploy script, no CI. Deployment guidance existed only
as two prose lines in each README.

Target shape is one reg.ru KVM box serving all four landings, each on its
own domain root. nginx serves the built SPA off disk and proxies only
/api/* to a small Express process per app, so a crashed or restarting API
takes down the form rather than the page. Releases are built on the
server into a timestamped directory and swapped in by renaming the
`current` symlink.

  deploy/apps.conf      domains and ports, the one place to edit
  deploy/README.md      hardware/software spec, provisioning, runbook
  deploy/bin/           exo-deploy, exo-render-nginx
  deploy/nginx/         vhost template, shared snippets, http extras
  deploy/systemd/       one template unit for all four instances
  deploy/env/           annotated templates for the two env files

exo-deploy asserts the VITE_SITE_URL substitution actually happened,
prunes devDependencies after building, precompresses for gzip_static,
health-checks after the swap and rolls back on its own if the new release
fails to answer. exo-render-nginx refuses to emit a vhost while a
placeholder domain is still in apps.conf.

Secrets are split across two env files: the amoCRM token stays in
/etc/exo at mode 640 and is injected by systemd, while only public
build-time vars are copied into a release. dotenv does not override
variables already in the environment, so the two coexist safely.

Chose systemd over Docker deliberately — no database, no conflicting
runtimes, no CI or registry to build images in, and containerising fights
the serve-static-from-disk design. Reasoning and the triggers to revisit
it are recorded in the README.

Domains are still placeholders; nothing here has been run against a
server yet.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

deploy/systemd/exo@.service

@@ -0,0 +1,36 @@
+# /etc/systemd/system/exo@.service
+# One template unit for all four landings: systemctl enable --now exo@fitnes
+[Unit]
+Description=EXO landing API (%i)
+After=network-online.target
+Wants=network-online.target
+
+[Service]
+Type=simple
+User=exo
+Group=exo
+WorkingDirectory=/srv/exo/%i/current
+EnvironmentFile=/etc/exo/%i.env
+# The server is TypeScript run directly by tsx — there is no server build step.
+ExecStart=/srv/exo/%i/current/node_modules/.bin/tsx server/src/index.ts
+Restart=always
+RestartSec=2
+SyslogIdentifier=exo-%i
+
+# Sandbox. The process only reads from /srv/exo and talks HTTPS to amocrm.ru.
+NoNewPrivileges=true
+PrivateTmp=true
+ProtectSystem=strict
+ProtectHome=true
+ProtectKernelTunables=true
+ProtectKernelModules=true
+ProtectControlGroups=true
+RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX
+RestrictSUIDSGID=true
+LockPersonality=true
+# Backstop, not a tuning target: expected RSS is 60-100 MB.
+MemoryMax=512M
+TasksMax=256
+
+[Install]
+WantedBy=multi-user.target