Merge pull request 'docs(readme): give operators an entry point before the build steps' (#30) from docs/installer-first-setup into main

Reviewed-on: #30
Reviewed-by: Colby Whitlock <whitlocktech@gmail.com>

README.md

@@ -12,11 +12,34 @@ ServUO plugin (C#, net48)  ──loopback TCP, newline-JSON──►  Rust sidec
 The shard never speaks WebSocket and exposes no port of its own — the sidecar is the only
 network-facing component, which is what keeps the game unreachable from the internet.
 
+## Running a shard? Don't build this
+
+The [**Runic Gateway installer**](https://gitea.whitlocktech.com/RunicGateway/installer) installs
+this sidecar for you — the released binary, its config, a hardened service account and the service
+registration — alongside the shard plugin, in one run, on Linux or Windows:
+
+```bash
+sudo ./runicgateway-installer-linux-x86_64 install
+```
+
+It ends by printing the base URL, WebSocket URL, protocol version and auth token to paste into
+**Admin → Shard** on your site. Guide:
+[installer/INSTALL.md](https://gitea.whitlocktech.com/RunicGateway/docs/src/branch/main/installer/INSTALL.md).
+
+Installing it yourself is supported too — the release binaries on this repo's
+[releases page](https://gitea.whitlocktech.com/RunicGateway/link/releases) are the same ones the
+installer fetches, and
+[INSTALL.md Appendix A3–A4](https://gitea.whitlocktech.com/RunicGateway/docs/src/branch/main/installer/INSTALL.md#a3-install-the-sidecar)
+covers placing the binary and registering the service by hand.
+
+Everything below this line is for **developing on the sidecar**.
+
 ## Related repos
 
 | Repo | What |
 |------|------|
 | **this** — `RunicGateway/link` | The Rust sidecar (`sidecar/`). |
+| [RunicGateway/installer](https://gitea.whitlocktech.com/RunicGateway/installer) | The **installer** — deploys this sidecar and the plugin onto a shard host. The supported way to set one up. |
 | [RunicGateway/servuo-plugins](https://gitea.whitlocktech.com/RunicGateway/servuo-plugins) | The **C# ServUO plugin** — the shard side of the bridge (`overlay/`, `patches/`, `deploy.ps1`, test scaffolding). |
 | [RunicGateway/docs](https://gitea.whitlocktech.com/RunicGateway/docs) | All project documentation — design docs, protocol spec, integration guide, research. |
 
@@ -28,9 +51,10 @@ network-facing component, which is what keeps the game unreachable from the inte
 | `.gitea/workflows/pr-checks.yml` | Gates every PR into `main` on `cargo fmt --check`, `cargo clippy -D warnings`, and `cargo test`. |
 | `.gitea/workflows/release.yml` | Builds + releases the sidecar binary (Linux + Windows) on every merge to `main`. |
 
-## Build & run
+## Build & run (development)
 
-The sidecar is a standard cargo crate:
+Building from source is for working *on* the sidecar; a deployment gets its binary from a release,
+via the installer or by hand. The sidecar is a standard cargo crate:
 
 ```bash
 cd sidecar
@@ -39,7 +63,7 @@ cp sidecar.toml.example sidecar.toml   # then edit
 cargo run --release
 ```
 
-Deploying it rather than developing on it: `--config <PATH>` names the config file (as does
+Deploying it by hand rather than developing on it: `--config <PATH>` names the config file (as does
 `$UOLINK_CONFIG`), and `--print-config` prints the resolved settings — **including the auth token
 the website needs** — as JSON, provisioning the config file on first run. That is the supported way
 to read the token back; it is not meant to be scraped from the log.