feat(kit): the event contract, taught and built (chapter 5)

The fifth chapter, and the template code it teaches out of. Events is the first
thing in the book that goes the other way — chapters 1-4 move data out of the
game and onto a page; an event changes a live world on a schedule, unattended.

**Chapter 5** covers the four declarations (budgets, option sources, leases,
actions), leads with the lease because EVENTS.md §H is right that it is the
primitive that travels and the spawn is the special case, and gives one section
each to the four things that are invisible until an outage: the envelope's
failure default, the idempotency passthrough, recording a resource before
confirming it, and under-declaring `cost`.

**Chapters 3 and 4 gain one section each** for the command plane, because
without them chapter 5 teaches a module to send an idempotency key to a sidecar
the book never told anyone to build a command path in. Both say at the top that
they are skippable until you want chapter 5.

**The template ships one of each declaration**, with `server/sidecarClient.js`
as the near end — a real timeout, a real key passthrough, a simulated transport
in one function marked for replacement. That file is named for the filename
`noGameConnection.test.js` already anticipated, so the test stays green now and
fires correctly the moment `deliver()` becomes a request.

Two things writing it found, both now in the chapter and beside the code:

  * **An idempotency key belongs on a command, never on a question.** The first
    draft keyed every call including the reads; an at-most-once store then
    answers every future read with the first one's reply, forever. The lease
    applied correctly and the module could no longer see it. Hence `ask` and
    `send` as two functions.

  * **A refusal's reason goes in `error`; core reads no other name.** The first
    draft used `detail`, on the strength of the one place EVENTS.md §H mentions
    it, and every refusal it produced was anonymous on the run console.

Proved by running the template's real declarations through core's real registry
at `edge` (all four accepted) and its real envelopes through the real
`events/dispatch.js` classifier.

**CI is RED on `checkCoreApi` and that is the mechanism working.** The template
now declares `coreApi: ^1.10.0` and `ci/core-ref.json` pins the engagement
cutover, where `main` is still 1.9.0. Equality is the check, a bump is meant to
turn this repo red until someone re-reads the chapters, and the pin move rides
in the events cutover (EVENTS_PLAN.md P16) as its own commit. Do not "fix" it.

Refs EVENTS_PLAN.md Phase 15, EVENTS.md §F, MODULE_API.md 1.10.0.

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

book/03-sidecar.md

@@ -89,6 +89,52 @@ A module cannot do any of this from inside the website process. There is nowhere
 put what arrives while the website is not running, because the website not running
 is exactly the case.
 
+## 2a. The other direction, if you ever want events
+
+Everything above is about data leaving the game. Skip this section until you want
+[chapter 5](05-events.md) — but read it *before* you build the sidecar rather than
+after, because retrofitting it is more work than allowing for it.
+
+An event on the website is core telling your module *"do this to the world now"*,
+and your module telling your sidecar, and your sidecar telling the game. That is a
+**command** — a request with a reply, going the way nothing above goes. It needs
+three things the read path does not.
+
+**Request/reply correlation.** A command is not a broadcast: the caller waits for
+an answer and has to know which answer is theirs. `uo-link` does this in
+`sidecar/src/rpc.rs` — an id on the way out, a map of pending calls, the reply
+matched back and the waiter woken. You need it for reads that ask the game a live
+question too, so it is often already there; commands are what make it load-bearing.
+
+**An idempotency key, executed at most once, stored where the game is.** Core hands
+your module a key that is a function of the step's identity and never of the
+attempt, so every retry carries the same one. The far end must execute a given key
+once and answer a repeat with **the reply the first attempt produced** — not by
+running the command again.
+
+That store belongs as close to the game as the state it protects. A store in the
+sidecar is right for a command whose effect is the sidecar's own; a command that
+changes the *world* needs the store where the world is, because the case it exists
+for is the game restarting mid-run. And a repeat arriving while the original is
+still in flight is its own answer — "busy", transient by construction, because the
+work is happening.
+
+Without this, a command that arrived, ran, and whose acknowledgement was lost is
+indistinguishable from one that never arrived. The only safe policy is then never
+to retry, which means a game restarting mid-event writes the step off.
+
+**A deadline the game enforces on its own.** A borrowed value — a doubled gather
+rate, a raised spawn cap — carries an expiry down the wire, and the game side must
+restore the baseline when it passes **without being asked again**. The website's
+copy of that deadline is for the console. The game's copy is the fail-safe: if the
+website is never heard from again, the value still comes back.
+
+Two details that are easy to get wrong and expensive to change later. Send the
+deadline as a **duration**, not an absolute time — two machines' clocks are two
+clocks. And if the borrowed value lives in the game's own save file, the *hold*
+must be persisted and the timer re-armed at load; a restart preserves the change
+and destroys only the thing that would have undone it.
+
 ## 3. The wire is a versioned contract, not a build dependency
 
 Your sidecar and your module ship separately, on different schedules, to hosts you