docs(account): record step 3 (module hooks, kit re-pin) as built

ACCOUNT_DELETION.md: status line, and §6 step 3 marked built with what went beyond
§4.4 (Module-uo queues before calling, also retries on a live server.hello, clears
pending rows on a webId-less login, lists them via GET /admin/uo-link/config).
modules/uo/SCHEMA.md: the new shard_pending_unlinks table, and the table count
corrected (it was already stale: 33 tables, 32 shard_* plus uo_link_config).

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

modules/uo/SCHEMA.md

@@ -1,6 +1,6 @@
 # module-uo — the tables it owns
 
-The 27 tables `module-uo` creates and owns, and the reasoning behind their shapes. **26 `shard_*`
+The 33 tables `module-uo` creates and owns, and the reasoning behind their shapes. **32 `shard_*`
 plus `uo_link_config`**, all created by the idempotent `server/db/schema.sql` fragment core replays
 after its own schema on every boot, and all dropped by `server/db/purge.sql` when an operator purges
 the module's data.
@@ -263,6 +263,36 @@ same way — `uo-static-3922-h33-<sha8>.png`. A key the shard has no art for wri
 an empty row would make it "held" and it would never be asked again, including after the operator
 patches in the graphic that was missing.
 
+## shard_pending_unlinks — what an account deletion left linked on the shard (MODULE_API 1.20.0)
+
+When a website account is deleted, core asks the module first (`api.onUserDeleting`,
+[`ACCOUNT_DELETION.md`](../../website/ACCOUNT_DELETION.md) §4.4). `shard_account_links` is only a
+mirror: the shard keeps the site user id on the game account and reports it as `webId` on every
+`mob.login`, so the module unlinks each game account on the shard, through the staff unlink's
+`DELETE /link/{account}` (actor `web:account-deletion`), before the users row goes. This table is
+what that unlink could not finish.
+
+| Column | Meaning |
+|---|---|
+| `account` | PK, the game account |
+| `web_user_id` | the deleted user's id, which the shard may still report |
+| `state` | `pending` (the shard was away) or `refused` (a protected staff account, 403) |
+| `queued_at`, `attempts`, `last_attempt_at`, `last_error` | the retry's own record |
+
+Four rules that are load-bearing:
+
+- **Every linked account is written here BEFORE the first call to the shard**, and dropped when the
+  shard answers 200 or 404 (404: nothing to clear). Core gives the hook 10 s and one sidecar call can
+  take 12, so a hook core stops waiting for still leaves everything it had not finished queued.
+- **No foreign key, on purpose.** Every row outlives the user it names; that is the point of it.
+  The mirror row in `shard_account_links` goes with the users cascade either way.
+- **`pending` is retried; `refused` never is.** The retry runs when the WebSocket opens (which is
+  also the boot path, since boot never calls the shard) and on every live `server.hello`. A refused
+  row waits for the shard's staff to clear the tag by hand; Admin → Shard lists both kinds as *Still
+  linked on the shard*, from `GET /admin/uo-link/config`'s `pendingUnlinks`.
+- **A live `mob.login` on the account with no `webId`, or another one, clears the row**, whoever
+  cleared the tag. A replayed login never does: one from before the link carries no `webId` either.
+
 ## shard_clilocs / shard_cliloc_meta — UO's localization table (Protocol 3.0)
 
 Items on the wire carry a `LabelNumber`, not a name. The bridge has always sent it —