docs(rust): the step-2 site walk, and the run it found stuck pending

Walked on a core running Module-Rust#22 on website#209 against rust-oxide:
F8, F13/F14, F7, F5/F6 and the helper's state all pass. The expiry walk found
a run left cleanup-pending for ever when its last resource expires while it
runs; website#209 now settles it, and EVENTS.md §L says so.

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

modules/rust/PLAN_FIXES.md

@@ -399,9 +399,15 @@ in Rust-Plugins, Rust-Link and Module-Rust, and the three cut over to `main` tog
    installer#35 and website#209 (core's `expired` status, MODULE_API 1.11.0). The spec is
    [`PROTOCOL.md`](../../rust-link/PROTOCOL.md) §19.4–19.8. Walked on both rigs without a player: the
    bridge and the ZoneManager helper compile and load, the helper patches ZoneManager 3.1.14, the hello
-   carries its state, and `plugin.loaded` / `plugin.unloaded` carry the right permissions. Still to walk:
-   the site side (a walk core running Module-Rust#22 on website#209), and the rows of
-   [`PLAYER_WALK.md`](../../rust-link/PLAYER_WALK.md)'s step-2 section that need somebody in the game (3–9).
+   carries its state, and `plugin.loaded` / `plugin.unloaded` carry the right permissions. The site side
+   was walked the same night on a walk core running Module-Rust#22 on website#209, against `rust-oxide`: the
+   servers list shows the helper `patched`; a Kits unload and load was synced as `dirty` 24 s later (F8);
+   a 3-minute zone expired into `expired` with `resource.expired` and teardown never touched it (F13, F14)
+   — which found a run left `pending` for ever when its last resource expires while it runs, fixed in
+   website#209; a restart's sync waited for `worldReady` and went after it (F7); and `ZZZZZZ` with five
+   servers down answered "unknown or has expired", once, in one timeout (F5, F6). Still to walk: the rows
+   of [`PLAYER_WALK.md`](../../rust-link/PLAYER_WALK.md)'s step-2 section that need somebody in the game
+   (3–9).
 3. **The redesigns**, each planned in detail before code and walked on both frameworks: the permission manager
    (§4.1), the event step editor with the kit-weekend template (§4.2, §4.3), zones and domes (§4.4), the map's
    marker types (§4.5), the chat title conditions (§4.6), and the NPC research (§4.7).

rust-link/PLAYER_WALK.md

@@ -414,8 +414,9 @@ Added 2026-09-27. What [`PLAN_FIXES.md`](../modules/rust/PLAN_FIXES.md) §8 asks
 step 2's fixes, in the order they are quickest to walk. Player A from the walks above; a staff member
 at the website. **Run it on Oxide and on Carbon.** Rows marked *no player* need nobody in the game.
 Their game side was walked on both rigs on 2026-09-27 (the helper patched, the hello carried its state,
-the load frames carried Kits' permissions); their site side waits for a walk core running Module-Rust#22 on
-website#209. The rest need somebody in the game.
+the load frames carried Kits' permissions), and their site side on `rust-oxide` the same night (the servers
+list showed the helper; the Kits load was synced 24 s later). Row 8's refusal and events step 6 were also
+walked there without a player. The rest need somebody in the game.
 
 | # | Do this | You should see |
 |---|---|---|

website/EVENTS.md

@@ -1805,7 +1805,9 @@ It is **terminal and green, like `reverted`**: it releases the target (it is not
 hold it), it is not "unreverted", and the sweep never tries to give it back. A row a revert has already
 claimed (`reverting`) is left to that revert, which finds nothing and succeeds. A finished run whose last
 unresolved row this was goes to `cleanup_status = 'complete'`, including from `incomplete`, which the
-sweep no longer scans.
+sweep no longer scans. A run still going when its last resource expires is settled by the sweep once it
+ends: finished, `pending`, and no unresolved row is `complete` — the scan that joins on an unresolved row
+could not see it, and the step-2 walk's run 46 sat `pending` until it could.
 
 ---