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

rust-link/PROTOCOL.md

@@ -2989,8 +2989,12 @@ credit block. A protocol-13 plugin still sends them, and the site still adds the
   **`EventsMaxWorldCalls`** (config, default and ceiling 10) world events per run, counted over every call the
   run made; behind `EventsEnabled`. A count the game partly ran answers `called` below `count`.
 - Refusals are `world.error`: `not-ready`, `events-disabled`, `malformed` (no key or run, or a key over 128
-  characters), `bad-event`, `bad-count`, `not-placeable`, `too-many`, §15's location refusals, and `refused`
-  (the game had nothing to run).
+  characters), `bad-event`, `bad-count`, `not-placeable`, `too-many`, §15's location refusals, `refused`
+  (the game had nothing to run), and **`already-out`**: a `travelling_vendor` call while a Travelling Vendor is
+  already out. The game runs one at a time, so nothing is called, counted toward `EventsMaxWorldCalls` or kept
+  (W3, Rust PLAN_LAST_FIXES; before, the call answered `called: 1` and spawned nothing). Module-Rust reads it as
+  a success that called 0, and the step's note says *"a Travelling Vendor is already out on Main, and the game
+  runs one at a time; nothing new was called"*.
 - `world.monuments` gains `maxWorldCalls`.
 
 **Hello and status gain `console`: `{ "plugins": true | false }` (D363).** Whether this framework runs a plugin's
@@ -3568,8 +3572,11 @@ the old assembly, and the helper patches again. `rgr.status` prints its state.
 - **The unload trap (§11.4.2):** a RaidableBases unload raises `Completed` for every live base with no owner
   and no raiders. **Such a completion is neither sent nor counted.**
 - `raid.purchased` and `raid.locked` come from the paid edition's `OnRaidableBasePurchased` and
-  `OnRaidableBaseLocked`: a player bought a base, or an admin ran `rbevent setowner` (D390). **Lockouts have no
-  hook in either edition and are not sent.**
+  `OnRaidableBaseLocked` (D390). A player buying a base raises `raid.purchased`. An admin's
+  **`rbevent setowner <player> lockout`** raises `raid.locked`. **The plain `rbevent setowner <player>` raises
+  `raid.purchased`**, as if the player had bought it, because RaidableBases' `TrySetPayLock` takes
+  `paylock = !args.Contains("lockout")` (W23, found in the end walk). **Lockouts** (the per-player cooldown
+  after a raid) **have no hook in either edition and are not sent.**
 - `despawnAt` is the plugin's despawn time, in unix milliseconds.
 - **None is sent while the world is not live** (§20.5's rule). A completion is still counted.
 
@@ -3666,7 +3673,12 @@ reloads the profiles as `rb.reloadprofiles` does**, and the reply is `pending` a
 (§19.1). The `config.outcome` (`reload: "RaidableBases"`) settles when the helper's reload finishes: every
 written profile in the plugin's table is `reloaded`; one that is not is **rolled back** and the old file
 reloaded. Thirty seconds without a finished reload rolls back too. RaidableBases rewrites every profile file as
-it reloads, so the outcome carries each file's version as it is on disk afterwards.
+it reloads, so the outcome carries each file's version as it is on disk afterwards. **A rollback's log is
+RaidableBases' own** (W9, Rust PLAN_LAST_FIXES): the bridge marks the server log's position when the job
+starts, and reads back only RaidableBases' entries written since (tagged `[RaidableBases]`, which is how it
+logs on both frameworks, or its title), without their stacks. When the failed profiles are named, only the
+entries that name them are kept. When RaidableBases said nothing, there is no log, and the reason line stands
+alone. Before, the outcome carried the tail of the server log, which is mostly other plugins' lines.
 
 **Hooks.** `OnRaidableBaseStarted`, `OnRaidableBaseEnded`, `OnRaidableBaseCompleted`, `OnRaidableBasePurchased`
 and `OnRaidableBaseLocked` join `rg.hooks`' list.