docs(link): the panel, and the two deletions it could see and no test could (Phase 8)

v8.md section 12.2 records the admin surface as built: one page, Admin -> Client
Files, over the creature catalogue, item and land art, and the cliloc table --
one page because they come off one client install and change on one event. The
four decisions are written down, including the one that kept the phase to a
single repo: section 14's "activity view" is the last import's own summary
rather than a filtered feed, which would have needed a core activity filter, a
`ctx.activity.list` helper and a MODULE_API bump to re-read rows the panel can
keep itself.

The part worth reading twice is what the walk found. Two of the three defects
were DELETIONS, both predate phase 8, and neither was reachable by a test that
did not already suspect them:

  * the body import diffing its manifest against every family's rows, so 313
    item pictures were staged for deletion under a sentence that was wrong about
    what had happened;
  * an approved vanish unlinking the sprite and keeping the row, so the key came
    back for review forever and the count never moved.

The rule they share is now stated: after phase 5, `shard_assets` is three
collections in one table, and every read of it that feeds a decision has to say
which one it means. Two of the three that did not were deletions.

CLILOCS.md and SPAWN_ATLAS.md now name the button that exists (Admin -> Client
Files) instead of the one they promised, and modules/uo/API.md records that a
`needsReview` reply carries each vanished key's picture.

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

website/SPAWN_ATLAS.md

@@ -288,7 +288,7 @@ so as of [`v8.md`](../link/v8.md) phase 3 it decodes them itself and hands the
 pictures to the website over the bridge. Nobody installs UOFiddler and nobody
 copies images to a web host.
 
-**Admin → Shard → Import.** The import walks the shard's asset manifest, fetches
+**Admin → Client Files → Update.** The import walks the shard's asset manifest, fetches
 only the sprites whose hash changed, writes them under `uploads/atlas/`, asks the
 shard for a body id per creature (§8 — the shard constructs the creature and
 reads `Body.BodyID`, which is the only thing that is right for a shard's own