docs(link): two of the eight player bodies existed, and 233 nobody asked about (Phase 4)

Phase 4 built 4.3's UOP animation reader. What it found first changed what the phase
was worth, so the plan is corrected rather than merely annotated.

  - New 4.9: what phase 4 measured. Of the EIGHT player bodies 4.8 assigned this
    phase, two are in the client at all -- gargoyles 666/667, in AnimationFrame3.uop.
    The six ghost bodies are in no package, and that is established rather than
    unfound: the five packages hold 10,724 entries and the
    build/animationlegacyframe/%06d/%02d.bin scheme claims every one, leaving no room
    for another naming. Also the format as read (AMOU, a per-frame ARGB1555 palette,
    direction as a slice of the frame table), the nine bodies whose frame count is not
    a multiple of five, the validate-as-we-go bounds and the measurement that says
    they refuse nothing real, and the live rig.
  - 5.2 rewritten: the player-body set is the LIVING pair per race, six ids not
    twelve. Ghost ids left it because no client has art for any of them. Still asked
    of the shard, never hardcoded -- only the question changed. And with phase 4 in,
    all six have art for the first time.
  - 4.3 rewritten against what was measured, including why searching five UOP packages
    for one body is NOT the never-sweep rule being broken: a legacy index is addressed
    by position, a UOP entry by the hash of a name carrying the body id, which the
    payload then declares again.
  - 11 sizing: the catalogue is 1,022, not 787. The mix is recorded because "add every
    body" sounds like it changes what a catalogue is, and it does not -- the legacy
    787 was already 366 equipment bodies.
  - 14: manifest and fetch rows carry `source` (legacy/uop). Additive, so protocol
    stays 8; EXTRACTOR_VERSION 1 -> 2 is the change consumers actually see.
  - 16 phase 4 marked DONE; 17.9 records the four org-lead decisions (fallback applies
    to every body; ghost ids leave the set; own PNG encoder; NO_IMAGING stays flat).
  - 4.8 and 8.1 keep their numbers as the record of what those phases measured, with a
    pointer to where the answer landed.

Two consumer docs repeated the ghost claim as fact and are corrected:
website/SPAWN_ATLAS.md (787 -> 1,022, and "two thirds of the playable ghost and
gargoyle bodies have no art" -> about half the addressable body range) and
modules/uo/API.md (same sentence).

Code: servuo-plugins#31.

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

website/SPAWN_ATLAS.md

@@ -233,15 +233,16 @@ custom creatures) and points each `shard_spawn_creatures.art` at its picture.
 Boot never calls the shard for this: the files change when an operator patches
 their client, which is an event they know about and the site does not.
 
-On this machine's stock client that is **787 creature portraits**, about a
-megabyte in total.
+On this machine's stock client that is **1,022 creature portraits**, about a
+megabyte in total — 787 out of the legacy `anim*.mul` files and 235 more out of
+`AnimationFrame*.uop`, which ServUO's own decoder never opens
+([`../link/v8.md`](../link/v8.md) §4.9).
 
 **NULL stays a first-class state, and always will be.** An install with no shard
 link has never imported one; a Linux shard host without `libgdiplus` cannot
-render a sprite at all (a named `NO_IMAGING` status, not an error); and even
-after a complete import, two thirds of the playable ghost and gargoyle bodies
-have no art in the client. Pages render without images, which is normal and
-supported, not degraded.
+render a sprite at all (a named `NO_IMAGING` status, not an error); and about
+half the addressable body range has no art in any client file. Pages render
+without images, which is normal and supported, not degraded.
 
 ### The operator's own artwork still wins