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/CLILOCS.md

@@ -173,8 +173,10 @@ reason: This is a compressed (Mythic-format) cliloc file, which the site cannot
   imports nothing when the shard is the source. A sidecar round trip in the boot
   sequence would be spent answering "no" on every restart but the one after a
   client patch — and patching a client is an operator action, so importing is an
-  operator action. **Admin → Shard → Import** is the button. Whatever table is
-  loaded keeps serving until then.
+  operator action. **Admin → Client Files → Update** is the button (the cliloc
+  section of it; the page covers everything that comes off the UO client, because
+  a client patch changes all of it at once). Whatever table is loaded keeps
+  serving until then.
 - **Still hash-gated**, so pressing Import when nothing changed costs one small
   call. The gate is the shard's own `assets.sources`: size, mtime and content
   hash of `Cliloc.enu` plus the shard's `EXTRACTOR_VERSION`. A `sha256` of `null`
@@ -318,7 +320,9 @@ unconditional.
 
 ## Admin surface
 
-All admin-only, alongside the atlas under Admin → Shard:
+All admin-only, and driven from **Admin → Client Files** — one page over the
+cliloc table, the creature catalogue and item art, since all three are read from
+the same client install (docs/link/v8.md §12.2):
 
 | Route | Purpose |
 |---|---|

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