Merge pull request 'docs(account): record step 6, the account deletion walk' (#397) from docs/account-deletion-step6-walk into main

Reviewed-on: #397

website/ACCOUNT_DELETION.md

@@ -390,5 +390,58 @@ Asked while building core (§6 step 2), the same day:
    - the deleted staff username is refused at registration and at a username change
    - the demo refuses
    - the last admin is refused
+
+   **Walked 2026-10-30**, every row passing. Two local cores at website `7bd93b8`, one module
+   each, on throwaway databases: Module-Rust `edge` `e30c7d5` linked to the Carbon rig (Rust
+   26139947, Carbon 2.0.262, both the latest), and Module-uo `main` `148cf0f` with the local
+   ServUO on servuo-plugins `main` and a uo-link sidecar built from link `main` (protocol 8). The
+   app was the step 4 build on the `s22_ultra` emulator.
+   - **Website, UO-linked.** A player linked to `seed_000` through the real `[link` code, with a
+     second session open on a phone token, deleted the account from */account*. The site showed
+     "Your account has been deleted.", and the phone token answered 401 on its next request.
+     The shard's `WebsiteUserId` tag was gone, the log held `shard.account.unlink` with
+     `reason: account deleted`, and Admin → Shard listed nothing still linked. A game login over
+     a real socket before the deletion sent `mob.login` with `webId: "2"`. The same login after
+     it sent no `webId`.
+   - **Sidecar stopped.** A second linked player deleted their account while the sidecar was
+     down. The deletion answered 200 at once, `seed_002` was queued as `pending` with the error
+     `fetch failed`, and Admin → Shard listed it under *Still linked on the shard*. The shard
+     still held the tag. When the sidecar started again, the ingest socket connected and the
+     queued unlink finished within a second. The row cleared and the tag was gone.
+   - **Forum.** The deleted player's two threads in their guild's Team forum read
+     "[deleted player]" to a member, on the thread and on the post, in the API and on the guild
+     page. Staff saw "uwplayer1 (deleted account)" there, with the moderation controls.
+   - **App, Rust-linked.** A player linked to a stand-in Steam id held `autodoors.use`, granted
+     from the site, and the app's *My Rust account* showed it as "Carbon rig · has it". They
+     deleted the account in the app while a web session stayed open. The app opened sign-in,
+     and the web cookie answered 401 on its next request. The log held `rust.account.unlink`.
+     The next permission sync, 29 s later, pushed one revoke, and `c.show user` on the rig
+     listed no permissions.
+   - **Staff name.** A moderator deleted their own account. `RwMod` was then refused at
+     registration ("That username is already taken.") and as rwmember's new username on
+     */account*. An unused name registered.
+   - **Demo.** With `DEMO_MODE=true`, `demo-player` saw "This is turned off on the demo site."
+     on */account*, and an admin's `DELETE /admin/users/:id` on that account answered 403
+     `DEMO_LOCKED`. An ordinary account on the same demo deleted itself.
+   - **Last admin.** The UO site's only admin was refused on */admin/account*: "You are the only
+     admin. Make someone else an admin before you delete your account."
+
+   The walk used stand-ins in two places. The Steam link was written straight into
+   `rust_account_links`, because the rig had no second player to type `/link`. The `[link`
+   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.
+   - **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.
+   - **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.
 7. Then `USER_SAFETY.md` (report, block and hide, now 1.21.0), then `android/PLAN.md` M8's
    cutover.