docs(book): name Oxide, and the question "how many sidecars" answers

Follows the org lead's two corrections on docs#170. The Rust example is an OXIDE
plugin - naming the framework is the difference between a design a reader can
start from and one they have to go and choose for themselves - and the
architecture pairs one sidecar to one game server, on that server's own host.

Chapter 3 gains the general form of that second one, since it is the chapter
where a reader decides what to build: if your game runs as a fleet, "how many
sidecars" is answered by where the loopback boundary is, not by how many
processes you would rather run. Your module holding several clients is the
cheaper end of that trade, and core never learns there is more than one.

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

book/03-sidecar.md

@@ -151,13 +151,22 @@ shape. That is what thin means: less code, the same architecture.
 
 **Rust is the worked example, and it is not that case.** The dry run in
 [`rust-dryrun.md`][dryrun] designs a module for it precisely because it shares so
-little with Ultima Online — and its answer is a **mod**: a plugin loaded by the
-server's own mod framework, hooking the game's events and dialling out to a
-sidecar, exactly as the ServUO overlay does. The Rust server is a *binary*, where
-ServUO is source a shard owner compiles, so the way in is a published hook API
-rather than a file you edit. **The three-part shape survives that unchanged**,
-which is the more useful finding: the plugin-dials-out arrangement is not a
-property of having source access.
+little with Ultima Online — and its answer is an **Oxide plugin**: C# loaded by
+the mod framework a modded Rust server already runs, hooking the game's events and
+dialling out to a sidecar, exactly as the ServUO overlay does. The Rust server is a
+*binary*, where ServUO is source a shard owner compiles, so the way in is a
+published hook API rather than a file you edit. **The three-part shape survives
+that unchanged**, which is the more useful finding: the plugin-dials-out
+arrangement is not a property of having source access.
+
+It also pairs **one sidecar to one game server**, on that server's own host,
+rather than one sidecar fronting a community's several — because those servers sit
+on separate machines, and a shared sidecar would be reached across a network by
+plugins that are supposed to talk to it over loopback. Worth knowing before you
+design yours: if your game runs as a fleet, the question "how many sidecars" is
+answered by where the loopback boundary is, not by how many processes you would
+rather run. Your module holding several clients is the cheaper end of that trade,
+and core never learns there is more than one.
 
 That document reached the game over RCON until 2026-08-19, and before that
 concluded there should be **no sidecar at all**. It carries both corrections,