docs(readme): describe a released installer, not an unreleased one

The status section still said "Phases 1 to 4 are built, on edge. Nothing
is released yet" and told visitors the way to install was by hand — both
untrue as of v0.1.0.

- Add an "Install a shard with it" section up top: verify, run, paste the
  four values. That is what a visitor to this repo is here for.
- Status: released, all five phases, both cutover gates recorded.
- Fix a broken link: bundles/current.json is no longer on main, it lives
  on the bundles branch.

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

README.md

@@ -25,9 +25,48 @@ It also **does not replace ServUO startup behavior.** ServUO keeps running throu
 its existing release/start scripts; the installer never writes a launcher and
 never restarts the shard.
 
+## Install a shard with it
+
+Grab a binary and `SHA256SUMS` from the
+[releases page](https://gitea.whitlocktech.com/RunicGateway/installer/releases),
+verify the checksum, and run it as Administrator/root against a **stopped** shard:
+
+```bash
+sha256sum -c SHA256SUMS --ignore-missing
+chmod +x runicgateway-installer-linux-x86_64
+sudo ./runicgateway-installer-linux-x86_64 install
+```
+
+```powershell
+# Windows, from an elevated PowerShell
+.\runicgateway-installer-windows-x86_64.exe install
+```
+
+It ends by printing the four values to paste into **Admin → Shard** on your site.
+The full operator guide — what it asks, where it writes, the patch tier, day-two
+commands and troubleshooting — is
+[`installer/INSTALL.md`](https://gitea.whitlocktech.com/RunicGateway/docs/src/branch/main/installer/INSTALL.md).
+
+Prefer to place everything yourself, or on a host that cannot run the binary?
+[INSTALL.md Appendix A](https://gitea.whitlocktech.com/RunicGateway/docs/src/branch/main/installer/INSTALL.md#appendix-a--installing-by-hand)
+is the same deployment done with `curl`, `tar` and `systemctl`, and stays
+supported.
+
 ## Status
 
-**Phases 1 to 4 are built, on the `edge` branch. Nothing is released yet.**
+**Released.** All five phases are built and the `edge → main` cutover (#17) cut
+the first release, [`v0.1.0`](https://gitea.whitlocktech.com/RunicGateway/installer/releases),
+publishing `linux-x86_64`, `linux-aarch64` and `windows-x86_64.exe` with
+`SHA256SUMS`.
+
+| Phase | State |
+|---|---|
+| 0 — prerequisites in the other repos | ✅ merged |
+| 1 — installer core: bundle resolution, ServUO detection, overlay sync, `install.json` | ✅ released |
+| 2 — uo-link install + service registration | ✅ released |
+| 3 — the opt-in stock-file patch tier | ✅ released |
+| 4 — `doctor`, `update`, `uninstall` | ✅ released |
+| 5 — packaging polish: Linux `aarch64`, backup before overwrite | ✅ released |
 
 The binary does everything
 [`installer/INSTALL.md`](https://gitea.whitlocktech.com/RunicGateway/docs/src/branch/main/installer/INSTALL.md)
@@ -40,39 +79,18 @@ The design of record is
 in the docs repo: phases, locked decisions, and the Phase 0 prerequisites in other
 repos (a `servuo-plugins` release workflow, a non-interactive config read-back in
 `link`, and the bundle-manifest CI here), all of which have landed —
-[`bundles/current.json`](bundles/current.json) names the current protocol-checked
+[`bundles/current.json`](https://gitea.whitlocktech.com/RunicGateway/installer/src/branch/bundles/current.json)
-sidecar + overlay combination, recomposed on every component release and nightly
+names the current protocol-checked sidecar + overlay combination, recomposed on
-(see [`bundles/README.md`](bundles/README.md)).
+every component release and nightly (see [`bundles/README.md`](bundles/README.md)).
 
-| Phase | State |
+**`main` publishes.** `release.yml` cuts a release from every push to `main`, which
-|---|---|
+is why the crate was integrated on `edge` until it was worth handing to an
-| 0 — prerequisites in the other repos | ✅ merged |
+operator. Both cutover gates were met first: Phase 5 (its scope settled as **no
-| 1 — installer core: bundle resolution, ServUO detection, overlay sync, `install.json` | ✅ on `edge` |
+`.deb` and no MSI** — either would give the sidecar binary, its service unit and
-| 2 — uo-link install + service registration | ✅ on `edge` |
+its service account a second owner beside this tool), and the **Windows SCM half
-| 3 — the opt-in stock-file patch tier | ✅ on `edge` |
+verified on a real host**. That second one earned its place: `sc start` failed
-| 4 — `doctor`, `update`, `uninstall` | ✅ on `edge` |
+with 1053 on its first real run and needed a sidecar fix (link#29) before it
-| 5 — packaging polish: Linux `aarch64`, backup before overwrite | in progress |
+passed 13/13.
-
-**Why `edge`:** `release.yml` publishes an installer binary on every push to
-`main`, so nothing lands there until the whole tool is worth handing to an
-operator. The `edge → main` cutover cuts the first release. PRs into `edge` run
-the same gates as PRs into `main`.
-
-**What the cutover is waiting on**, per PLAN.md §5:
-
-1. **Phase 5**, packaging polish — deliberately *before* the first release rather
-   than after it, because it changes the release layout, and shipping first would
-   mean a first release immediately superseded by the next. There is no `.deb`
-   and no MSI: both would give the sidecar binary, its service unit and its
-   service account a second owner beside this tool.
-2. **The Windows SCM half verified on a real host.** `sc create`, the virtual
-   service account, the failure actions and the token-file ACL have never been
-   executed anywhere. Running the *systemd* half for real is what turned up a bug
-   no unit test had, so this is not a formality.
-
-Until the cutover, the way to install is by hand —
-[INSTALL.md Appendix A](https://gitea.whitlocktech.com/RunicGateway/docs/src/branch/main/installer/INSTALL.md#appendix-a--installing-by-hand)
-is the same deployment done with `curl`, `tar` and `systemctl`.
 
 ## Related repos