docs(link): phase 1 built the transport, and re-measured the catalogue

Asset Bridge phase 1, docs half. Code: RunicGateway/servuo-plugins#28,
RunicGateway/link#41.

## The correction, which is most of this

**New §4.8.** The animation path has §4.5's shared-buffer defect too, and 357 of the
1,144 bodies §1.1 counted are **wrong pictures on a stock client** — ids with `length 0`
that return whichever body was decoded before them. Proved by decoding body 320 after a
dragon (a dragon), a wolf (a wolf) and a human (a human).

So the catalogue is **787 bodies**, and the numbers that were derived from 1,144 move
with it: §11's working set, its ~173,000-frame full set (now ~119,000), phase 3's scope.

**§5.2's table was wrong in the direction that matters.** The elf ghosts were listed as
decoding; their index entry has no record, and what came back was the elf female. Four
of twelve player bodies have art, not six — which takes phase 4's UOP decoder from six
ids to eight.

§1.1 now says outright that every "decoded" count in it is an upper bound. It is not a
table to size anything from any more.

## What phase 1 settled

- **§3.3** — the two numbers: a 512 KiB batch budget under a 1 MiB inbound line cap, with
  the factor of two load-bearing rather than cautious.
- **§3.2** — flow control is enforced **on the shard**, as a single slot answering
  `bridge.busy`, not serialised in the sidecar and not left to the website as a
  convention. Records what it costs: a status poll shares the slot.
- **§3.4, new** — one paging envelope (`more`/`cursor`/`cut`) for all five families that
  will page, defined before the first one needs it. `cut` because "short page" has three
  meanings and only one of them means finished.
- **§6** — hashing had to come off the request path entirely. The gate is unchanged; what
  changed is that "the normal case must cost nothing" now also means "and the abnormal
  case must not time out", because the first hash of 1.06 GB does not fit in 10 s.
- **§14** — which commands exist now, and which phase brings the rest.
- **§16, §17** — phase 1 done; decisions 6 and 7.

## Elsewhere

- **`SHARD_PREREQS.md`** gains the libgdiplus requirement (§4.4) — Linux hosts only, with
  the archived-upstream caveat and the `NO_IMAGING` status the shard now reports on the
  source gate.
- **`INTEGRATION.md`** advertised `X-UOLink-Version: 6`. It was already two versions stale
  before this change; now 8.

- [x] AI-assisted — Claude Code (Opus 5)

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

link/SHARD_PREREQS.md

@@ -69,3 +69,44 @@ World: Loading...
 ## Unrelated, still open
 
 `DllNotFoundException: zlibwapi64` crashed this shard once (`Crash 6-5-2026-22-38-3.log`) while sending a packed gump. `zlibwapi64.dll` is present in the repo root, so this is a working-directory / native-load-path problem. It will bite the bridge if the bridge ever triggers a gump send. Resolve before load testing.
+
+---
+
+## Host prerequisite: `libgdiplus` on Linux (Protocol 8)
+
+Everything above is a repair to one shard's *scripts*. This one is different in kind: it is a
+requirement on the **host**, it applies to every shard, and only to Linux ones.
+
+The Asset Bridge ([`v8.md`](v8.md) §4.4) has the shard read art out of the operator's own UO client
+files. ServUO targets `net48`, so on Linux it runs under Mono, and Mono's `System.Drawing` is a thin
+layer over **libgdiplus** — which sits in the **decode** path and not merely the encode:
+`Ultima.Frame` writes ARGB1555 through a `LockBits` pointer. Without that library a Linux shard
+cannot read a sprite at all.
+
+**Windows shard hosts need nothing.** `System.Drawing` ships with .NET Framework.
+
+| Host | Get it with |
+|---|---|
+| Debian / Ubuntu | `sudo apt-get install libgdiplus` — in Debian since bullseye (6.0.4) and bookworm/trixie (6.1), and in Ubuntu universe |
+| Fedora / RHEL | `sudo dnf install libgdiplus` (EPEL or the Mono repository) |
+| Docker | `RUN apt-get update && apt-get install -y libgdiplus` in the shard image |
+| Alpine, or a distro with no package | Build from source. This is the awkward case, and it is worth avoiding by choosing a Debian-based image |
+
+Upstream is <https://github.com/mono/libgdiplus>. **That repository was archived in March 2025** and
+is read-only; distributions still package and patch it, so installing it is a normal supported thing
+to do today, but nobody is maintaining it upstream. It is the strongest long-term argument for
+eventually moving extraction off `System.Drawing`.
+
+**Its absence is not an error and never a crash.** The shard reports a named status on the source
+gate — the first call any import makes — so an operator meets this while setting the shard up rather
+than as an empty bestiary weeks later:
+
+```
+imaging: { ok: false, code: "NO_IMAGING",
+           reason: "This shard host cannot render images — Mono's System.Drawing needs
+                    libgdiplus. Install it (apt-get install libgdiplus) and re-run the
+                    import. Cliloc and atlas import are unaffected." }
+```
+
+Clilocs and the ServUO tree files are genuinely unaffected: neither touches a pixel. The installer's
+`doctor` checks for this alongside its other host checks.