docs(events): the acceptance walk, and the three contracts it moved (Phase 16a)

Phase 16 is split into 16a (the walk), 16b (the cutover) and 16c
(runicgateway.com + .profile), because the phase as written asked for a walk
"against released artefacts" BEFORE the cutover and all three component repos
release on push to `main`. The walk therefore runs against artefacts built from
`edge` the way a release builds them, and 16b re-verifies against the real bundle.

`EVENTS_PLAN.md` gains the 16a record: the rig, all three deliberate failures
passing, the six defects, the one finding withdrawn, and what each fix was
verified against.

Three contracts move, each because the walk proved the built thing did not match
the written one:

**`link/v6.md` — a refusal does not spend its key.** Rule 2 had two cases, throw
and return, and needed a third: a handler that ran to completion and deliberately
refused did nothing, so freezing that refusal as the key's answer made a refusal
that WAITING FIXES impossible to retry past. The section now carries the case
`uo.world.save` found it with, and the rule the release rests on — do not answer
`*.error` after changing the world. `[bridge status` gains `refused=`.

**`website/MODULE_API.md` — `revert`'s `idempotencyKey` identifies a dispatch; it
is not a key to send on the undo.** The paragraph explained what the key is FOR
and never said what it is not, and `module-uo` read it the other way: every
despawn went out under the key its spawn had used, so a store that keys on the key
alone answered the undo with the DO's reply and teardown became a no-op that
reported success.

**`website/EVENTS.md` §I — the public calendar matches a run that OVERLAPS the
window.** The row promised "upcoming, live and recent" and the built route served
only the first, because it read the start instant and a live run has already
started. The default window now reaches back so "recent" has somewhere to live,
and projections are forecast from now rather than into that tail.

Pairs with `website#`, `Module-uo#` and `servuo-plugins#`.

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

website/MODULE_API.md

@@ -1193,6 +1193,16 @@ rather than implementation and belong here:
   with the key and an EMPTY list, meaning *"a command went out under this key and core never learned
   what it did"*. Answering that honestly is what makes an unattended world write recoverable; a
   module that cannot answer it says so, and the row stays visible to an operator.
+- **That key IDENTIFIES a dispatch; it is not a key to send on the undo.** It names the command core
+  lost the answer to, so the module can ask the game about it. Forwarding it as the outgoing key of
+  the reverting command is a different thing entirely, and on a game whose at-most-once store keys on
+  the key alone — as the uo-link shard's does — the undo is then recognised as a repeat of the DO and
+  answered with the original reply. `module-uo` made exactly this mistake: teardown of all five world
+  verbs was a no-op that reported success, because every despawn carried the key its spawn had gone
+  out under. Found by the Phase 16 acceptance walk, with the ledger reading `reverted` and the shard
+  still holding every object. A command that undoes needs a key of its own or none at all; a repeated
+  undo is usually harmless by construction ("already gone" is a success), which is what makes *none*
+  the right answer more often than not.
 - **Core owns cleanup, and it is derived rather than authored.** There is no `on_teardown` on an
   action and no cleanup phase in a spec: an operator cannot be relied on to write the undo, and an
   aborted run never reaches the phase they wrote it in. Cleanup is one sweep over the ledger and it