docs(book): a mod is a plugin too, and RCON is not the Rust answer

The kit taught, to an audience outside this org, that Rust needs "no game-side
plugin to write at all" because it ships RCON. That is overruled: the Rust dry
run reaches the game through a MOD - a plugin loaded by the server's own
framework, hooking events and dialling out - exactly as the ServUO overlay does
(docs#170).

Chapter 3's section kept its question and lost its example, which turned out to
improve it. The useful test is not "does my game expose a protocol" but "does it
DELIVER EVENTS": a remote-control channel is built for an operator typing
commands and tells you what you asked about, when you ask, and a website needs
what happened whether or not anyone was listening. A channel that answers
questions can only be polled, and polling turns "someone left the clan at 14:02"
into "the count was different at 14:03".

Rust now appears in that section as the counter-example rather than the example,
and carries the finding that is actually worth having: its server is a BINARY
where ServUO is source you compile, and the three-part shape survives that
unchanged. The plugin-dials-out arrangement is not a property of having source
access.

Chapter 4 said a game with a remote-control protocol may not need any of it, and
that its worked example is source you build. Both now say what is true - the
rules in that chapter are properties of being inside a game loop, and apply
identically to a mod in a closed server.

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

README.md

@@ -43,9 +43,11 @@ in the contract ([`MODULE_API.md`][api] §2.7, `MODULE_API_VERSION` 1.4.0), not
 style preference, and chapter 3 is mostly about why. The short version: the
 website is the internet-facing process and your game is not; the sidecar persists
 before it forwards, so a website that is down or mid-deploy loses nothing; and a
-game must never block on a web request. A game that already exposes a
-remote-control surface — Rust's RCON over WebSocket, say — needs a *thin* sidecar,
-not none.
+game must never block on a web request. A game that genuinely delivers events on a
+surface of its own needs a *thin* sidecar, not none — but check that it delivers
+events rather than answering questions, because a channel built for an operator
+typing commands can only be polled, and polling turns "someone left at 14:02" into
+"the count was different at 14:03".
 
 ## Start here