feat: documentation site

Docusaurus 3 docs-only site at docsite/, served statically by nginx under
/docs on the marketing host. Covers getting started (self-hosted install
through first server and first licence), the control plane, Vantage HQ,
a reference section and operations.

Wired into docker-compose.site.yml as docsite (3005:80) and into the
image build workflow, rebuilding on its own directory only. Never added
to the self-hosted compose file.

docs/vantage/servers.md

@@ -0,0 +1,98 @@
+---
+id: servers
+title: Servers
+sidebar_label: Servers
+---
+
+The fleet. Every managed machine runs an agent that connects outbound to the
+control plane, and everything else in Vantage — keys, workflows, monitors,
+consoles — targets these records.
+
+## Enrolling a server
+
+Covered step by step in [Add your first server](../getting-started/first-server.md).
+In short: **Servers → Add server** issues a single-use, one-hour token and shows
+a one-liner to run as root on the target machine.
+
+## Lifecycle
+
+| Status | Meaning |
+| --- | --- |
+| `pending` | Enrolment created; the agent has not registered yet |
+| `active` | The agent registered and is syncing |
+| `offline` | Last-seen passed the threshold |
+
+The offline sweep runs every two minutes, so a machine that has just gone away
+takes a little while to be marked as such. That delay is intentional — a single
+missed poll is not an outage.
+
+## The server detail page
+
+### Keys
+
+Which SSH keys are assigned to this machine, and their state. See
+[SSH keys](./ssh-keys.md).
+
+### Inventory
+
+Agents report:
+
+| Data | Refreshed |
+| --- | --- |
+| CPU, memory, swap, load | every 30 seconds |
+| Partitions, kernel, full static snapshot | every 15 minutes |
+
+The two carry separate timestamps, so a stale static snapshot beside fresh
+metrics is normal rather than a fault.
+
+### OS updates
+
+Agents check for pending package updates hourly and report the count. From the
+server page you can:
+
+- **Apply updates** — pushes `ApplyUpdatesCmd` down the command stream. The
+  agent runs the platform's package manager and reports back.
+- **Update agent** — pushes `UpdateAgentCmd` with a target version; the agent
+  downloads the release, verifies it and replaces itself. See
+  [Agent updates](../operations/agent-updates.md).
+
+:::warning Applying updates is not scheduled or staged
+It runs now, on that machine. If you need ordering, health gates or a canary,
+build it as a [workflow](./workflows.md) instead — that is what workflows exist
+for.
+:::
+
+### Console
+
+Opens a browser SSH, RDP or VNC session. See [Browser console](./browser-console.md).
+
+## Windows servers
+
+Windows agents register, heartbeat, run workflow steps and report inventory.
+They do not manage `authorized_keys` — the poll loop stops after the heartbeat
+on any non-Linux host. This is a deliberate scope decision, not a gap being
+worked on.
+
+## Removing a server
+
+Deleting the server record removes it from the fleet. It does **not** uninstall
+the agent, which will keep trying to sync and failing. Uninstall it on the
+machine too:
+
+```bash
+systemctl disable --now vantage-agent
+rm -f /usr/local/bin/vantage-agent /etc/systemd/system/vantage-agent.service
+rm -rf /etc/vantage
+systemctl daemon-reload
+```
+
+Keys previously written to `authorized_keys` stay on disk, because the agent is
+no longer running to remove them. Revoke and let the agent apply the change
+**before** you delete the server if that matters to you.
+
+## Agent tokens
+
+Each server has its own token. The control plane stores only its SHA-256; the
+plaintext exists in the agent's `0600` config and nowhere else. There is no way
+to read a token back out of the control plane — if one is lost, re-enrol the
+machine.