feat(screens): phase 9 — real screenshots, from a real shard

D4 asked for screenshots of the review stack rather than placeholders. Seventeen
of them: eleven of the site in a browser, six of the app on a phone, all from one
demo deployment wired to a running ServUO shard over a real sidecar, captured on
one day (D42).

The deployment is branded "Runic Gateway Demo" rather than a real community (D43),
and the captures sit beside the claims they support — the homepage, /features/, and
five of the administration pages phase 7 could describe but not show (D44).

The rig is committed rather than remembered (D45):

  scripts/seedDemo.mjs        content, by driving the site's own API — never SQL,
                              because a row the product could not have produced is
                              a screenshot of a product that does not exist
  src/data/screens.mjs        every capture: route, viewport, scroll, alt, caption
  scripts/captureScreens.mjs  npm run screens:capture
  scripts/checkScreens.mjs    the ninth check script, in CI

Shard-side dressing is servuo-plugins' scaffolding (D46), never deployed.

The rig found five things nothing else had. One is fixed upstream — a fresh
module-uo install pinned wire protocol 3 against a sidecar speaking 4, released as
v1.0.2, which this repo's own facts check then caught in platform.json. Four are
raised as product observations and worked around in the rig: a renamed guild
member never reaches the site, a guild deleted while the shard is down is a ghost
row forever, "Houses in danger" cannot show a house that was already collapsing,
and the app's news list prints raw ISO timestamps.

Players online reads 0. Logging a character in needs a UO client driven by hand,
and that is where this stopped — PLAN.md §10 says exactly why, and how to retake
the two frames that would change.

Co-Authored-By: Claude <noreply@anthropic.com>

src/content/docs/docs/administration/branding-and-theming.mdx

@@ -4,6 +4,7 @@ description: Colours, fonts and corners from the Appearance screen; logo, hero a
 ---
 
 import { Aside } from '@astrojs/starlight/components';
+import Screenshot from '../../../../components/Screenshot.astro';
 
 One prebuilt image runs as any community's site. Nothing about your identity is compiled
 in — it is a theme row in the database, three image files on a mount, and a few environment
@@ -31,6 +32,8 @@ Two things the screen tells you that are easy to miss:
 - **The accent reaches the mobile app and the Discord bot**, both of which theme themselves
   from this site's public branding. Changing it here changes them.
 
+<Screenshot id="admin-appearance" />
+
 ## Brand assets
 
 The same screen uploads three images, and each applies as soon as the upload finishes —

src/content/docs/docs/administration/managing-modules.mdx

@@ -4,10 +4,13 @@ description: The five states a module can be in, installing and upgrading, disab
 ---
 
 import { Aside } from '@astrojs/starlight/components';
+import Screenshot from '../../../../components/Screenshot.astro';
 
 Installing your first module is [Getting started](/docs/getting-started/install-a-game-module/).
 This is what the screen means afterwards.
 
+<Screenshot id="admin-modules" />
+
 ## The five states
 
 `installed → enabled → started`, with `disabled` and `startup_failed` as recoverable

src/content/docs/docs/administration/the-shard-connection.mdx

@@ -4,6 +4,7 @@ description: The module's shard screen — connection settings, what the status
 ---
 
 import platform from '../../../../data/platform.json';
+import Screenshot from '../../../../components/Screenshot.astro';
 import { Aside } from '@astrojs/starlight/components';
 
 With the `uo` module installed, **Shard (uo-link)** appears in the admin sidebar at
@@ -13,6 +14,8 @@ the controls that ride on it.
 Setting it up for the first time is
 [Connect a game server](/docs/getting-started/connect-a-game-server/).
 
+<Screenshot id="admin-shard" />
+
 ## Connection
 
 Four fields, all four printed by the installer, plus the switch that turns the integration

src/content/docs/docs/administration/users-and-roles.mdx

@@ -4,6 +4,7 @@ description: The four roles and what each one reaches, creating accounts, and in
 ---
 
 import { Aside } from '@astrojs/starlight/components';
+import Screenshot from '../../../../components/Screenshot.astro';
 
 ## The four roles
 
@@ -24,6 +25,8 @@ Admin routes are re-validated against the database on **every request**, not jus
 Demoting an account takes effect at once — the open session does not keep its access until
 it expires.
 
+<Screenshot id="admin-users" />
+
 ## Creating an account
 
 **Admin → Users → + Add user** creates one directly: username, password, role, and it is

src/content/docs/docs/getting-started/first-run.mdx

@@ -4,6 +4,7 @@ description: Signing in as the first admin, what the site does before anyone vis
 ---
 
 import { Aside, Steps } from '@astrojs/starlight/components';
+import Screenshot from '../../../../components/Screenshot.astro';
 
 The site is up and nobody can see it yet. That is the intended state: a new deployment
 **starts in maintenance mode**, showing visitors a "coming soon" page while the admin panel
@@ -33,6 +34,8 @@ minute, and see [Authentication](/docs/administration/authentication/) for what
 **Web Bot Activity** screen shows and how to lift a ban.
 </Aside>
 
+<Screenshot id="admin-dashboard" />
+
 ## What is already there
 
 The first boot seeds a working site rather than an empty one: