feat: the first pages, and what a browser walk found behind them

Phase 4. `/rust` is the server list and the module's landing page (D12);
`/rust/servers/:id` is one server with four tabs — feed, leaderboard, who is
on, wipes (D13). Everything selectable lives in the URL, so any view of the
page is a link. The feed and the presence list poll every twenty seconds while
the tab is visible and not at all when it is not (D14); the leaderboard and the
wipe list load once. `site.footer.status` is filled with a live server and
player count (D15).

Nothing on these pages calls a game server. Every field comes from this
module's own tables, which is what the phase criterion is about: the site
renders the last thing each server said while every server is off.

Walking that criterion in a browser against a live rig found four defects, two
of them already shipped in phase 3:

  * An unreachable refresh called `putState` — the whole-row write — with two
    fields, so a host that rebooted lost its hostname, map, size, seed and wipe
    id. The list then read "Offline" with nothing beside it, which is not "here
    is what we know" but "we have never heard of it". `markUnreachable` now
    moves three columns and mentions no others.
  * "Last reported" read `updated_at`, which a FAILED poll writes too — so an
    offline server claimed it had reported just now, every thirty seconds, for
    as long as it stayed down. `last_seen_at` is the new column, moved only by a
    frame that arrived.
  * Feed rows showed a bare time of day, so three events from six weeks ago all
    read as this afternoon once the feed was filtered to a past wipe.
  * `/rust/servers/typo` rendered core's ErrorState under its own heading and
    read "No such server / Something went wrong", sending a reader who mistyped
    a URL looking for an outage.

Also: a detail route (`GET …/servers/:id`), because it is the only route under
that path that can say a server does not exist — the other four answer an empty
list for an id nobody configured, and each of those is a good answer to its own
question.

`useAsync` cannot poll: it blanks its data on every dependency change, so a
twenty-second refresh built on it would clear the killfeed and re-fill it four
times a minute. `hooks/usePolled.js` is the module's own, invisible when it
succeeds and keeping the rows when it fails.

The client test fake was *nearly* core — it prefixed routes without stripping
the trailing separator, so the first module to register an index route failed
the nav check for a link that works in a browser. It now copies core's line
character for character.

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

client/src/components/FooterStatus.jsx

@@ -0,0 +1,73 @@
+// ── This module's fill for core's `site.footer.status` slot ───────────────
+//
+// R13, and the contract is MODULE_API.md §3.7. Core owns the position in the
+// footer's info row and the separator around it, and passes `linkStyle` so the
+// row stays visually one row. **The label, the destination, the data and whether
+// anything renders at all are this component's** — that is the whole division,
+// and it is why the slot is named for a place rather than for a meaning.
+//
+// ── The live count, and what it costs ─────────────────────────────────────
+//
+// The org lead chose a live count ("3 servers · 42 online") over a static link,
+// so this fetches. Be clear-eyed about where it fetches from: core renders
+// `SiteFooter` inside `PublicLayout`, and every public page renders
+// `PublicLayout` ITSELF (§3.3) — so this component mounts once per public page
+// view, not once per session. Every public page on the site therefore carries one
+// `/public/rust/servers` request, including pages that have nothing to do with
+// Rust.
+//
+// Two things keep that honest rather than merely cheap:
+//
+//  • **It renders NOTHING until it has an answer, and nothing again if the
+//    request fails.** An unfilled slot renders nothing and core's `wrap` takes
+//    the separator with it, so a failed fetch degrades to exactly the footer an
+//    instance with no module installed has. A spinner in a footer would be worse
+//    than silence on every page of the site.
+//  • **It never polls.** One request per page view is a cost; a timer in the
+//    footer of every page would be a different kind of thing entirely.
+//
+// If that per-page request ever shows up in an operator's logs as a problem, the
+// fix is a short-lived module-scope cache here — the decision to keep the number
+// live stays intact, and nothing else on the site has to change.
+
+import { useEffect, useState } from 'react'
+import { Link } from 'react-router-dom'
+import api from '../api.js'
+
+export default function FooterStatus({ linkStyle }) {
+  const [summary, setSummary] = useState(null)
+
+  useEffect(() => {
+    let live = true
+
+    api.servers
+      .list()
+      .then(({ servers }) => {
+        if (!live) return
+        // `online` already accounts for staleness — the model refuses to let a
+        // row that has not been written in five minutes claim a server is up —
+        // so this is a sum, not a judgement.
+        setSummary({
+          servers: servers.length,
+          players: servers.reduce((total, server) => total + (server.online ? server.players : 0), 0),
+        })
+      })
+      // Silence, deliberately. This is the footer of every page on the site; a
+      // module that cannot reach its own API has nothing to say there.
+      .catch(() => {})
+
+    return () => {
+      live = false
+    }
+  }, [])
+
+  if (!summary || summary.servers === 0) return null
+
+  return (
+    <Link to="/rust" style={linkStyle}>
+      {summary.servers === 1 ? '1 server' : `${summary.servers} servers`}
+      {' · '}
+      {summary.players === 1 ? '1 online' : `${summary.players} online`}
+    </Link>
+  )
+}