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/02-website-module.md

@@ -147,9 +147,10 @@ statement of your dependencies, and it makes a test double for it — see
 
 ## What you register
 
-Twelve calls — ten registrations and the two lifecycle hooks — all synchronous,
-all listed in [§2.4][api]. What is worth knowing is not their signatures but the
-model behind them.
+Nineteen calls, all synchronous and all listed in [§2.4][api]: fifteen
+registrations, the two lifecycle hooks, and the two identity-link hooks. Five of the
+registrations are the event system's, and [chapter 5](05-events.md) has those. What
+is worth knowing is not their signatures but the model behind them.
 
 **Every call stages; nothing is committed until your whole module is known good.**
 The shape of a claim is checked at the call, so a malformed one throws with your
@@ -505,6 +506,37 @@ warm-up it never finished, and handing it a half-built world to tear down is wor
 than not closing cleanly. A module with no hooks at all still reaches `started`:
 having nothing to warm up is not the same as never having started.
 
+### When a player links a sign-in identity
+
+If your game has its own idea of an account, a player's Steam id for instance, you
+may want to know when somebody links that identity to their site account
+(`MODULE_API_VERSION` 1.17.0). Linking stays core's. Core verifies the identity
+with its provider and writes the link; your module may read what core verified,
+refuse a link, and hear one, and nothing more.
+
+```js
+api.onIdentityLinking(async ({ userId, provider, subject }) => ({ ok: true }))
+api.onIdentityLinked(async ({ userId, provider, subject, displayName }) => {})
+// and, from anywhere: ctx.identities.list(userId, provider)
+```
+
+- **`onIdentityLinking` is asked before the link is written**, for every provider,
+  so filter on `provider` yourself. Answer `{ ok: false, reason: 'in_use' }` when
+  the identity already belongs to somebody else in your game; the person reads
+  core's own *"already linked to another user"*. **It fails closed**: a throw, or no
+  answer within 5 s, refuses the link. That is the right direction for a check whose
+  whole job is to stop one game account landing on two people.
+- **Your `message` is logged, never shown.** Module text on the page would let
+  anybody craft a link that prints a sentence of their choosing on the account
+  screen.
+- **`onIdentityLinked` is told after the row exists**, and is awaited for 5 s so
+  the page the person lands on already shows what you made of it. Its failure is
+  logged and the link stands, so write it to tolerate a race: your own record may be
+  taken between the check and this call, and "theirs stands" is the answer.
+- **There is no unlink hook.** Unlinking removes only the sign-in, and a record your
+  module made from it is yours to keep or remove.
+- Neither hook can mint a session or change who is signed in.
+
 ## The schema fragment
 
 `template/server/db/schema.sql` is your tables. It is replayed **in full, at every