docs: make the installer the documented way to deploy the overlay

"## Deploy" led with deploy.ps1 and mentioned the installer only
afterwards, which is backwards now that the installer is released.

- Deploy leads with the installer, with the by-hand overlay copy
  (INSTALL.md Appendix A2) as the supported alternative.
- deploy.ps1 gets its own subsection as the developer path: it deploys
  from a working tree, which is the one thing the installer cannot do,
  and it installs no sidecar and checks no protocol pairing.
- CONTRIBUTING: note that changes reach shards through a release, so a
  change that only works when deploy.ps1 copies it does not ship.

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

CONTRIBUTING.md

@@ -33,6 +33,13 @@ under `overlay/` (or `patches/` for changes to stock ServUO files) and deploy:
 .\deploy.ps1 -ServerPath C:\path\to\servuo
 ```
 
+`deploy.ps1` deploys from *this working tree*, which is what you want while
+developing. It is not how a shard is set up: operators run the
+[Runic Gateway installer](https://gitea.whitlocktech.com/RunicGateway/installer),
+which syncs the released overlay tarball and installs the sidecar alongside it.
+Changes here reach shards through a [release](README.md#releases), so a change
+that only works when `deploy.ps1` copies it is a change that does not ship.
+
 - `overlay/` — copied over an install (the only thing `deploy.ps1` deploys).
 - `patches/` — unified diffs against stock ServUO for files we must modify.
 - `tools/` — never deployed: test scaffolding and stub sidecars.