docs(website): document account deletion core and MODULE_API 1.20.0

ACCOUNT_DELETION.md §6 step 2 is built (website feature/account-deletion).

- MODULE_API.md: 1.20.0, api.onUserDeleting (§1.1, §1.1 history, §2.4).
- BACKEND_DESIGN.md: reserved_usernames, DELETE /auth/me/account, the admin
  delete now running the same procedure, the demo lock row, and §6.6 on the
  procedure, the display rule and what goes and what stays.
- TEAMS.md: the forum's deleted-author rule is now "[deleted player]" for
  members and the stored name, marked, for staff.
- ACCOUNT_DELETION.md: AD12 (wrong password or code is 400, not 401) and
  AD13 (a deleted account drops off Forum guests), both asked of the org
  lead while building; §4.1 refusals carry codes; step 2 marked built.

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

website/TEAMS.md

@@ -1020,7 +1020,12 @@ the CMS's sanitiser), stored sanitised, and served without re-sanitising — the
 already follow. Writes go through `ctx.middleware.rateLimit`-equivalent core middleware.
 
 `ON DELETE SET NULL` on authors rather than `CASCADE`: deleting a user must not silently blow holes in
-a thread other people replied to. The post renders as "[deleted account]".
+a thread other people replied to. The username snapshot is kept, and who sees it depends on the
+reader (`ACCOUNT_DELETION.md` AD5, AD6; `server/src/utils/displayAuthor.js`): a member, a leader or
+a guest sees **"[deleted player]"**, and staff see the stored name marked *(deleted account)*. The
+same rule covers thread authors, uploaders, the Team digest mail, the grant and override records and
+the Reports queue. A deleted account's grant stays in the ledger and drops off the leader's *Forum
+guests* list, because a grant is matched by user id and there is none left (AD13).
 
 ### 5.3 Moderation stays separate from the site's moderation system