docs(rust): the last fixes' docs (N1 N2 W20 W22 W23) and stage 4's core docs

Stage 5 of PLAN_LAST_FIXES (docs#366).

- OPERATING.md: a RaidableBases section. Change its config with a
  restart, never a reload (N2); switching to the free edition rewrites
  a paid pack's profiles (N1).
- PLAN_REDESIGNS 14.3.4: no manual retry for Dangerous Treasures (Q39,
  W20); 11.4: which hook rbevent setowner raises (W23); 9.1 status.
- PLAYER_WALK: rows 2.2, 2.8 and 2.9, Before you start item 8 (BetterChat
  and the four title rules), Carbon's share trimmed to 2.11 (W22, W23).
- PROTOCOL: 20.5 world.error already-out (W3), 20.12 the rollback's log
  is RaidableBases' own (W9) and setowner's two hooks (W23).
- Core, from website#219: MODULE_SYSTEM 2.5 and MODULE_API 4.2 (one
  module at boot, W19), MODULE_API and EVENTS L (a resource's until read
  at reconcile, W1), EVENTS D/I/K and BACKEND_DESIGN (a draft's dry run
  carried by fingerprint, W5), EVENTS observability (W2's words).
- PLAN_LAST_FIXES: status, Q37-Q40 answers, 7 updated, 8 what was built.

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

website/MODULE_API.md

@@ -383,6 +383,16 @@ field:
   made a promise core has no way to keep. Anything that is not an explicit `{ ok: true, inForce: [...] }`
   leaves the ledger alone: **"I do not know" is never read as "it is gone"**, and a resource a module
   reports missing becomes `orphaned` rather than `reverted`, because nobody asked for it to go.
+- **A resource may carry `until`**, the instant the game will end it by itself (an ISO string or
+  epoch milliseconds; a value that does not parse drops the resource with a logged reason, like any badly shaped
+  one). Core keeps it on the ledger row. **A reconcile that finds a resource gone past its `until`
+  files it `expired`, not `orphaned`** (W1 in Rust `PLAN_LAST_FIXES.md`, 2026-10-22): the deadline
+  worked, nobody lost it. It writes the same `resource.expired` line as `ctx.events.expired()`, and a
+  finished run whose last unresolved row it was is marked cleaned up. Gone before its `until`, or with
+  none, is still `orphaned`, and a row past its `until` that the game still has stays in force. This
+  is why a module should report `until` for anything with its own timer: after an outage, the
+  reconcile can run before the game's own "it ended" reaches core. No version change: `until` was
+  already accepted, and only core's reading of it at reconcile is new.
 
 **A third joined in Phase 15, also on an envelope:**
 
@@ -1063,7 +1073,8 @@ one authoritative source by construction, and two modules answering "what Teams
 two disjoint sets under one table with no rule for merging them. A second registration is a
 collision, reported against the module that holds it — and it fails that module's whole load, which
 is why core's installer admits **one module per site** (`MODULE_SYSTEM.md` §2.5, decision 35) rather
-than leaving the collision to be discovered on the next restart. Three methods are required — a provider
+than leaving the collision to be discovered on the next restart, and why, since 2026-10-22, the loader
+refuses a second module directory at boot before it is required (§4.2). Three methods are required — a provider
 that could list Teams but not their members would leave core holding Teams it can never populate,
 which is not the same as a call that fails. The fourth is optional; see below.
 
@@ -2305,6 +2316,16 @@ Alphabetical by `id`, deterministically. There is no dependency resolution betwe
 the design of record puts it out of scope) and alphabetical order is the honest way to say so — any
 other order would imply a precedence that is not being computed.
 
+**The first module in that order is the only one that starts** (`MODULE_SYSTEM.md` §2.5, decision 35;
+W19, 2026-10-22). It holds the site whether or not it then loads. Every later directory with a
+`module.json` is recorded `startup_failed` at the `manifest` stage before step 1 below, and before any
+of its code is required, with a reason that names both modules and says the one that sorts first by
+name is the one that starts. The installer already refused a second module; this closes the
+hand-copied directory. No `MODULE_API_VERSION` change: nothing a module calls or declares is different,
+and a site with one module loads exactly as before. The collision checks below still reject a module
+that collides with **core**. Against another module they can no longer be reached, and they stay as a
+second line behind the rule.
+
 ### 4.3 Validation, in this order
 
 1. `module.json` parses; no unknown keys; `id` matches the directory.