docs(kit): pin core 1.17.0; teach 1.13.0 to 1.17.0 and one module per site

The pin moves from 0a37a44 (1.12.0) to 6890a74 (1.17.0, website#220),
past 1.13.0 to 1.16.0, which reached main in the same cutover. The
chapters were read again for all five versions:

- Chapter 5: a lease's example, an option row's note, a param's
  duration (1.13.0) and multiple (1.14.0), a retry's retryAfterMs
  (1.15.0), a dry run's warnings (1.16.0), and a new section on
  templates (1.13.0). "What to build, in order" gains a template as
  step 8.
- Chapter 2: a new section on the identity-link hooks and
  ctx.identities.list (1.17.0). The call count is corrected to
  nineteen; it said twelve, which was already stale at 1.10.0.
- Two core changes in that cutover carried no version bump, and both are
  taught. Chapter 1 now says a site runs one game module and the loader
  refuses the others, since a reader copying the template onto a UO or
  Rust core is the one it surprises. Chapter 5 now covers a resource's
  `until`, which reconcile reads.

The template declares none of the new members, so nothing it does
changed meaning. template/module.json's coreApi becomes ^1.17.0 for the
equality check.

Checks run at the new pin:
- checkCoreApi, links, rename sites and chapter paths all pass, and so
  do the script tests (10 and 11).
- The template's imports, build, externals and swagger checks pass.
- Tests pass: server 82, client 20.
- The template was loaded as `examplegame` into a real core of this code
  through core's own loader, and it registered. Loaded again beside
  module-uo, examplegame started and uo was refused with the reason
  chapter 1 quotes.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY

book/01-first-module.md

@@ -135,7 +135,7 @@ whether it is a directory; a symlink answers no, and your module is skipped in
 complete silence. This is the single most common way a first install appears to do
 nothing at all.
 
-Two more things that look like your module failing and are not:
+Three more things that look like your module failing and are not:
 
 - If core is running in a container, your files have to be on the volume core sees
   — `MODULES_DIR` (`/app/modules` under the shipped Compose file), not the
@@ -143,6 +143,14 @@ Two more things that look like your module failing and are not:
 - A core with a fresh database boots in **maintenance mode**, and public module
   pages sit behind the same maintenance gate core's own do. Your page will look
   broken while the site is not live yet.
+- **A site runs one game module.** If the modules directory already holds one, an
+  Ultima Online or Rust site's for example, only the directory whose name sorts
+  first starts. Every other is refused before any of its code is read, and its
+  reason on Admin → Modules names both modules. `examplegame` sorts ahead of `rust`
+  and `uo`, so on such a core yours starts and the site's own module does not. Try
+  your module on a core of your own, with nothing else in its modules directory.
+  This is [`MODULE_SYSTEM.md` §2.5][system]; the installer refuses a second module
+  too, so the rule only surprises someone copying directories by hand.
 
 ## What you should see
 
@@ -270,6 +278,7 @@ what `ctx` hands you and why it is handed rather than imported, what each
 module must never do.
 
 [api]: https://gitea.whitlocktech.com/RunicGateway/docs/src/branch/main/website/MODULE_API.md
+[system]: https://gitea.whitlocktech.com/RunicGateway/docs/src/branch/main/website/MODULE_SYSTEM.md
 [issues]: https://gitea.whitlocktech.com/RunicGateway/Integration-kit/issues
 [renamecheck]: ../scripts/checkRenameSites.js
 [acceptance]: https://gitea.whitlocktech.com/RunicGateway/docs/src/branch/main/modules/kit-acceptance.md