docs(account): W1-W3 from the deletion walk are fixed; correct rust PLAN 29.8

ACCOUNT_DELETION.md step 6: W1 (Module-Rust#71), W2 (Module-uo#48) and W3
(Rust-Plugins#47) move from "not fixed" to fixed. modules/rust/PLAN.md 29.8:
Carbon 2.0.262 no longer answers "user not found" for a never-seen Steam id;
it writes the grant or membership into one shared blank record held by every
never-seen id. The bridge now checks for a record first on Carbon.

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

website/ACCOUNT_DELETION.md

@@ -431,17 +431,21 @@ Asked while building core (§6 step 2), the same day:
    codes and the game logins came from a probe and a small socket client kept outside the repos.
    The deletion paths themselves were the real ones.
 
-   **Found, not fixed:**
-   - **W1 (Module-Rust).** `edge` holds an empty file named `Promise.reject(dup)`, committed by
-     step 3's PR (#70). It is a stray from a tool, not code.
-   - **W2 (Module-uo).** *Still linked on the shard* says "tried 1 time, and tried again when the
-     bridge reconnects" about a retry that has not happened yet.
+   **Found, then fixed (org lead, 2026-10-30):**
+   - **W1 (Module-Rust).** `edge` held an empty file named `Promise.reject(dup)`, committed by
+     step 3's PR (#70). It is a stray from a tool, not code. Removed in Module-Rust#71.
+   - **W2 (Module-uo).** *Still linked on the shard* said "tried 1 time, and tried again when the
+     bridge reconnects" about a retry that has not happened yet. It now says "It tries again
+     when the bridge reconnects." Module-uo#48.
    - **W3 (Rust bridge, not deletion).** On Carbon, a group membership for a Steam id the server
-     has never seen was reported as applied, but `c.show group` listed no users, and later
-     syncs found nothing to correct. A grant to the same id was reported as not landed and
-     landed on the next push.
+     had never seen was reported as applied, but `c.show group` listed no users. The cause was
+     worse than the symptom: Carbon writes such a grant or membership into one shared blank
+     record, which every never-seen id then holds until a restart ([`rust/PLAN.md`
+     §29.8](../modules/rust/PLAN.md)). The org lead chose to hold these until the player joins.
+     Rust-Plugins#47 checks for a record on Carbon before writing, and reports `notLanded` or
+     `pending` instead. It was proven on the rig before and after the change.
    - **Observed, unchanged:** `user.self_delete` names the id only, as §4.1 says, so the
-     activity log alone cannot tell staff which account deleted itself. The auth slow-down covers the delete route,
-     so a third call from one address took about 4 s.
+     activity log alone cannot tell staff which account deleted itself. The auth slow-down
+     covers the delete route, so a third call from one address took about 4 s.
 7. Then `USER_SAFETY.md` (report, block and hide, now 1.21.0), then `android/PLAN.md` M8's
    cutover.